- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 Mar 2012 12:42:50 +1100
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: Henrik Nordström <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Incorporated for -19. I used Roy's suggestion, except with "have" instead of "match". On 05/03/2012, at 4:54 PM, Roy T. Fielding wrote: > On Mar 4, 2012, at 7:41 PM, Mark Nottingham wrote: > >> Re-reading 2616, I think I agree (even if not entirely happy with it). >> >> Suggested rewrite: >> >> Index: p6-cache.xml >> =================================================================== >> --- p6-cache.xml (revision 1562) >> +++ p6-cache.xml (working copy) >> @@ -1484,12 +1484,12 @@ >> using it to satisfy a request without contacting it, even by caches that >> have been configured to return stale responses.</t> >> <t>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.</t> >> + then a cache MAY use the response to satisfy a subsequent request, >> + subject to any other restrictions on caching. However, the specified >> + field-name(s) &MUST-NOT; be sent in the response to a subsequent request >> + without successful revalidation with 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.</t> > > I think you want to say > > However, any header fields in the response that match the field-name(s) > listed &MUST-NOT; be sent in a response to a subsequent request > > ....Roy -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 6 March 2012 01:43:17 UTC