Subject: Re: Call for Adoption: SEARCH method

From: Glenn Block <[email-masked]>
Date: Wed, 4 Nov 2020 23:08:37 +0000

Hi all

This is great to see. I've been a fan of this method since I first learned about it years ago. Darrel Miller and I have had many conversations on this..

One place I think this would be valuable is for GraphQL usage. One of the common critiques of GraphQL is that the HTTP caching story is very limited, as by default all requests are via POST.

The GraphQL HTTP w/g has done some work to specify how different methods can be used but you are still limited by the fact that the query is sent via the query string.

HTTP SEARCH would be great for GraphQL allowing complex GQL queries to be sent in an HTTP friendly and cachable fashion.

Glenn

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: Glenn Block <[email-masked]>
Date: Fri, 6 Nov 2020 23:51:39 +0000

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.

________________________________
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 <[email-masked]<mailto:[email-masked]>> wrote:
On 7 Nov 2020, at 8:02 am, Ben Schwartz <[email-masked]<mailto:[email-masked]>> 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/