- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 6 Nov 2020 12:48:20 -0800
- To: Glenn Block <Glenn.Block@microsoft.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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!
Received on Friday, 6 November 2020 20:48:44 UTC