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

Re: Call for Adoption: SEARCH method

From: James M Snell <jasnell@gmail.com>
Date: Fri, 6 Nov 2020 15:36:26 -0800
Message-ID: <CABP7RbfKp8kCOuqsn8eDiyc64771gabrwy1Vd8HXc0_wSPakEg@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Mark Nottingham <mnot@mnot.net>, Glenn Block <Glenn.Block@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Assuming there's (a) a mechanism to allow a reasonable cache key to be
derived, (b) there's implementer support, then there shouldn't be a
problem.

On Fri, Nov 6, 2020, 15:32 Ben Schwartz <bemasc@google.com> wrote:

> 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:36:52 UTC

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