Re: [EXTERNAL] Re: Call for Adoption: SEARCH method

I kind of agree with Ben on this though not completely as I see the semantic value of being able to express that I am sending a payload but it is for safe/idempotent purpose as opposed to POST which is anything goes.

I would MUCH prefer we support full caching, and this is what would make this most appealing for GraphQL usage.

Glenn Block (he/him/his) | M365 Core Ecosystem | @gblock <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fgblock&data=04%7C01%7CGlenn.Block%40microsoft.com%7C8b67f4d44ba14854defb08d85b6e0918%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637359875442888782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zKA721Dufo%2FIGdCEl%2FlHXmlCVokJ2QbNDTZjN%2BAo7ZE%3D&reserved=0> | Principal PM Lead | Schedule with me!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbook.ms%2FGlenn.Block%40microsoft.com&data=04%7C01%7CGlenn.Block%40microsoft.com%7C8b67f4d44ba14854defb08d85b6e0918%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637359875442898783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ZXDdKU%2FltooMs6XE5Zcyd899Byru2gHDA%2Btd4XSno0%3D&reserved=0>

________________________________
From: Ben Schwartz
Sent: Friday, November 6, 2020 3:32 PM
To: Mark Nottingham
Cc: James M Snell; Glenn Block; HTTP Working Group
Subject: [EXTERNAL] Re: Call for Adoption: SEARCH method

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<mailto:mnot@mnot.net>> wrote:
On 7 Nov 2020, at 8:02 am, Ben Schwartz <bemasc@google.com<mailto: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/