- From: Henry Story <henry.story@gmail.com>
- Date: Thu, 5 Nov 2020 17:51:57 +0100
- To: Ben Schwartz <bemasc@google.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
> On 5 Nov 2020, at 17:45, Ben Schwartz <bemasc@google.com> wrote: > > The draft says "The response to a SEARCH request is not cacheable.". Why is that? Semantically, it seems that caching keyed by the request body should behave correctly. > > RFC 7234 says "it is also possible to cache ... responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.". > > Without support for caching, I don't have any reason to prefer this method over POST. With support for caching, this would have been very useful in DoH. I also had concerns about this. My guess is that this comes from overlooking the browser as one of the most important caches around, especially with the move to TLS everywhere. A browser should be able to implement some of the query languages directly so that if it has a representation locally it can query that representation without downloading the remote one. Henry > > On Tue, Nov 3, 2020 at 8:10 PM Mark Nottingham <mnot@mnot.net> wrote: > As discussed in the October 202 Interim, this is a Call for Adoption for the HTTP SEARCH method draft: > https://tools.ietf.org/html/draft-snell-search-method-02 > > Please indicate whether you support adoption in response to this e-mail; information about intent to implement (or use) it is also useful. > > The Call for Adoption will end on 18 November 2020. > > Cheers, > > Mark and Tommy > >
Received on Thursday, 5 November 2020 16:52:13 UTC