Re: Call for Adoption: SEARCH method

[Ben Schwartz <[e-mail]>]

James, according to RFC 7234 Section 3:

>    A cache MUST NOT store a response to any request, unless:
>    o  The request method is understood by the cache and defined as being
>       cacheable


I think it follows that you do not need to declare this method
non-cacheable; you can declare it cacheable when keyed by exact match on
the body.  Existing intermediaries will not cache it anyway, since they do
not understand the method.

On Fri, Nov 6, 2020 at 3:52 PM James M Snell <[e-mail]> wrote:

> Yes, essentially. The caching restriction applies only to HTTP
> intermediaries and exists largely because existing intermediaries have
> no existing way of caching based on the body of the request.
> Applications, however, can cache however they see fit.
>
> On Thu, Nov 5, 2020 at 8:34 AM Glenn Block <[e-mail]>
> wrote:
> >
> > Looking again over the spec, I see that it specifically states in
> section 2 the response is NOT cacheable:
> >
> >  The response to a SEARCH request is not cacheable.  It ought to be
> >    noted, however, that because SEARCH requests are safe and idempotent,
> >    responses to a SEARCH MUST NOT invalidate previously cached responses
> >    to other requests directed at the same effective request URI.
> >
> >
> > Right after that, the draft states it supports conditional SEARCH,
> IF-Match etc.
> >
> > Am I correct that this means that a server can return an ETAG with a
> response, and the client can technically cache that along with the ETAG and
> use the ETAG in a subsequent conditional SEARCH?
> >
> > Glenn Block (he/him/his) | M365 Core Ecosystem | @gblock | Principal PM
> Lead | Schedule with me!
>
>