Subject: Call for Adoption: SEARCH method

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

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 <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: James M Snell <[email-masked]>
Date: Fri, 6 Nov 2020 12:48:20 -0800

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 <[email-masked]> wrote:
> Glenn Block (he/him/his) | M365 Core Ecosystem | @gblock | Principal PM Lead | Schedule with me!

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 6 Nov 2020 16:02:29 -0500

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 <[email-masked]> wrote:

> > 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?
> >

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 7 Nov 2020 10:23:33 +1100

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

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 6 Nov 2020 18:32:09 -0500

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]> wrote:

> 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.
>

---

From: James M Snell <[email-masked]>
Date: Fri, 6 Nov 2020 15:36:26 -0800

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.

---

From: Glenn Block <[email-masked]>
Date: Fri, 6 Nov 2020 23:46:41 +0000

Hi James

Thanks for clarifying. One suggestion would be to consider making the verbiage harder by specifying intermediaries.

Regarding the body, what if we had some sort of identifier like in the query string or in a header (Vary) that would allow the result to be cached? Like maybe a hash of the query?

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: James M Snell <[email-masked]>
Sent: Friday, November 6, 2020 12:48 PM
To: Glenn Block <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: [EXTERNAL] Re: Call for Adoption: SEARCH method