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

From: Mark Nottingham <[email-masked]>
Date: Sat, 3 Mar 2012 11:22:41 +1100

So, it seems like we have three options:

1. leave it alone.

2. align the language in no-cache with that in private.

3. deprecate the semantics of these values (but still allow them syntactically).

Personally, I'm in favour of #3; I love using esoteric features of caching, but this one has never been useful IMO.

What's your preference?

On 21/02/2012, at 8:10 PM, Henrik Nordström wrote:

> tis 2012-02-21 klockan 15:27 +1100 skrev Mark Nottingham:
> 
>> Notice that private is about whether the specific field-names can be
>> stored, where no-cache is about validation. 
> 
> There is no way in HTTP to revalidate headers other than to not cache
> them and only use any new values seen from a revalidation response.
> 
>> These are two very different behaviours, which is why I think this is
>> underspecified and an interop problem.
> 
> It's two slightly different wordings with the same result and meaning.
> 
> These headers MUST NOT be given from cache when servicing future
> requests from a cached copy of this response, or any older responses
> it's merged with.
> 
> It's possible that the description of private really mean to say MUST
> NOT store, not MUST NOT cache, making them differ on where the headers
> must be filtered (storing in cache vs reading from cache), but end
> result in responses to future requests is the same regardless.
> 
> 
>>>>     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.
> 
> I remember the discussion, but it's kind of pointless and
> counter-productive to have this note in the specification in the longer
> perspective.
> 
> This holds for pretty much any other MAY there is in the specification,
> these are not widely implemented. There is reasons why these are MAY and
> not SHOULD.
> 
> Regards
> Henrik
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 03 Mar 2012 14:58:21 +1300

> Personally, I'm in favour of #3; I love using esoteric features of caching, but this one has never been useful IMO.

I'm in favor of #2.

Despite its absence from implementations (so far) it is a useful feature 
which allows bandwidth optimisation in edge cases where stale-if-error 
breaks. For example; some optional client-specific headers with generic 
entity.

The big confusion around no-cache is that is *is* cacheable. I think 
that needs clarifying right at the top of its description.

Proposal:
"

   no-cache

       The no-cache response directive indicates that the response message
       is may become stale at any time and MUST NOT be used to satisfy a
       subsequent request without successful validation on the origin
       server.  A cache MAY store the response.

       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,
       whereas it MAY send the remainder of the response message.

"

Changes:
  * aligns paragraph phrasing from private with suitable word repacement for no-cache.
  * adds two MAY's about cache practice to clarify interoperability expectations by servers.
  * drops the explicit mention of use-cases ("This allows ...") since the other directives do not mention specifics

AYJ

---

From: Henrik Nordström <[email-masked]>
Date: Sat, 03 Mar 2012 03:33:26 +0100

> Personally, I'm in favour of #3; I love using esoteric features of caching, but this one has never been useful IMO.

They have good use for site tracking cookies. If sites start using them
caches are likely to follow.

My preference is 2 or maybe 1. Original 2616 wording in no-cache is not
very confusing imho even if the validation part is practically nonsense.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 5 Mar 2012 14:41:01 +1100

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>      
       <t> <x:h>Note:</x:h> 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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 4 Mar 2012 21:54:07 -0800

> Re-reading 2616, I think I agree (even if not entirely happy with it).

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Mar 2012 12:42:50 +1100

Incorporated for -19. I used Roy's suggestion, except with "have" instead of "match".