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 <mnot@mnot.net> wrote: > On 7 Nov 2020, at 8:02 am, Ben Schwartz <bemasc@google.com> 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/ > >
Received on Friday, 6 November 2020 23:32:35 UTC