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. On Fri, Nov 6, 2020, 15:32 Ben Schwartz <bemasc@google.com> wrote: > 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:36:52 UTC