W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: SEARCH method

From: Ben Schwartz <bemasc@google.com>
Date: Fri, 6 Nov 2020 18:32:09 -0500
Message-ID: <CAHbrMsD4kQA3pAbCntMMsXeMrHSfT5K3ODoT6XofV2JzAVnUZg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: James M Snell <jasnell@gmail.com>, Glenn Block <Glenn.Block@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
To clarify an earlier message: I would support adoption if the response is
made cacheable (useful new capability), and oppose otherwise (redundant
with POST).

On Fri, Nov 6, 2020 at 6:23 PM Mark Nottingham <mnot@mnot.net> wrote:

> On 7 Nov 2020, at 8:02 am, Ben Schwartz <bemasc@google.com> wrote:
> >
> > 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.
>
> I'm hoping we can do better than that. E.g., the request media type can
> define how it can be canonicalised into input for the cache key.. Or a
> response header might describe how to do it, a la Variant.
>
> But that's getting ahead of the CfA...
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

Received on Friday, 6 November 2020 23:32:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 6 November 2020 23:32:36 UTC