- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 21 Feb 2012 15:27:18 +1100
- To: Henrik Nordström <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 16/02/2012, at 6:37 PM, Henrik Nordström wrote: > mån 2012-02-13 klockan 15:56 +1100 skrev Mark Nottingham: > >> I had a look at this. I think we can fix things for private -- proposal is to change: >> >> ... That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message. >> >> to >> >> ... That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message (and subsequently reuse it). > > Ok. > >> However, the semantics of these arguments on no-cache is much less >> clear. IME this isn't implemented, so I'd suggest deprecating it by >> changing: > > qualified no-cache == qualified private, except that private only > applies to shared caches. That's not how they're currently specified. Private says: > If the private response directive specifies one or more field- > names, this requirement is limited to the field-values associated > with the listed response header fields. That is, a shared cache > MUST NOT store the specified field-names(s), whereas it MAY store > the remainder of the response message. whereas no-cache says: > If the no-cache response directive specifies one or more field- > names, this requirement is limited to the field-values associated > with the listed response header fields. That is, a cache MUST NOT > send the specified field-name(s) in the response to a subsequent > request without successful validation on the origin server. This > allows an origin server to prevent the re-use of certain header > fields in a response, while still allowing caching of the rest of > the response. Notice that private is about whether the specific field-names can be stored, where no-cache is about validation. No-cache doesn't indicate whether the response can be served from cache without those headers, or whether it has to revalidate to check their values. These are two very different behaviours, which is why I think this is underspecified and an interop problem. > >> If the no-cache response directive specifies one or more field- >> names, this requirement is limited to the field-values associated >> with the listed response header fields. That is, a cache MUST NOT >> send the specified field-name(s) in the response to a subsequent >> request without successful validation on the origin server. This >> allows an origin server to prevent the re-use of certain header >> fields in a response, while still allowing caching of the rest of >> the response. >> >> Note: Most HTTP/1.0 caches will not recognize or obey this >> directive. Also, no-cache response directives with field-names >> are often handled by implementations as if an unqualified no-cache >> directive was received; i.e., the special handling for the >> qualified form is not widely implemented. > > I don't see a need for bloating the specification with this note. It do > not add any value, only confusion. That note has been in there for quite some time, and was added based upon previous discussion. -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 21 February 2012 04:27:46 UTC