W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

Re: Question on draft-ietf-httpbis-cache-latest / RFC7234

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 3 Dec 2019 12:56:58 +1100
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <9CDBB11D-7AC0-47EA-9D89-147C5EC802CC@mnot.net>
To: Matthias Pigulla <mp@webfactory.de>

> On 18 Nov 2019, at 8:30 pm, Matthias Pigulla <mp@webfactory.de> wrote:
> Dear HTTP Working Group,
> this is my first contact ´╗┐with this WG. I've tried my best to read about the necessary procedures and practices. If this the wrong place or way to ask, please excuse me and advise.

This is a good place to ask this kind of question.

> My question is on the semantics of the "private" and "public" Cache-Control directives as defined at https://tools.ietf.org/html/draft-ietf-httpbis-cache-06#section- and https://tools.ietf.org/html/draft-ietf-httpbis-cache-06#section-, respectively.
> Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable".
> To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (https://tools.ietf.org/html/draft-ietf-httpbis-cache-06#section-3) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? 
> Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?

You're correct, and I think that's a good clarification. I've opened this issue to track:


Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 3 December 2019 01:57:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC