W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #337: Field names in cache-control header arguments

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sun, 4 Mar 2012 21:54:07 -0800
Cc: Henrik Nordström <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <15B7DF59-2E73-43DF-B6CD-0C30A1EDE75D@gbiv.com>
To: Mark Nottingham <mnot@mnot.net>
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
Received on Monday, 5 March 2012 05:54:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT