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

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 <jasnell@gmail.com>
Sent: Friday, November 6, 2020 12:48 PM
To: Glenn Block <Glenn.Block@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: [EXTERNAL] Re: Call for Adoption: SEARCH method

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 <Glenn.Block@microsoft.com> wrote:
>
> 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 | Principal PM Lead | Schedule with me!