Subject: #168: understanding CC directives

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jun 2010 15:55:25 +1000

p6 currently states:

  The "Cache-Control" general-header field is used to specify directives that
  &MUST; be obeyed by all caches along the request/response chain.

but as Jamie points out in <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/168>, this doesn't work so well with extension CC directives.

I think the intent is preserved with:

"""
  The "Cache-Control" general-header field is used to specify directives for caches along the request/response chain. HTTP/1.1 caches
MUST obey the requirements of the Cache-Control directives defined in this section. See [ref to CC extensions] for information about how Cache-Control directives defined elsewhere are handled.
"""

Thoughts?

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Jun 2010 10:45:54 +0200

On 02.06.2010 07:55, Mark Nottingham wrote:
> but as Jamie points out in<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/168>, this doesn't work so well with extension CC directives.
>

Looks good to me. That being said, I rearranged the sentences and ended 
up with:

3.2.  Cache-Control

    The "Cache-Control" general-header field is used to specify
    directives for caches along the request/response chain.  Such cache
    directives are unidirectional in that the presence of a directive in
    a request does not imply that the same directive is to be given in
    the response.

    HTTP/1.1 caches MUST obey the requirements of the Cache-Control
    directives defined in this section.  See Section 3.2.3 for
    information about how Cache-Control directives defined elsewhere are
    handled.

       Note: HTTP/1.0 caches might not implement Cache-Control and might
       only implement Pragma: no-cache (see Section 3.4).

    Cache directives MUST be passed through by a proxy or gateway
    application, regardless of their significance to that application,
    since the directives might be applicable to all recipients along the
    request/response chain.  It is not possible to target a directive to
    a specific cache.

      Cache-Control   = "Cache-Control" ":" OWS Cache-Control-v
      Cache-Control-v = 1#cache-directive

      cache-directive = cache-request-directive
         / cache-response-directive

      cache-extension = token [ "=" ( token / quoted-string ) ]

(see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/168/i168.diff>).

Ticket 168 furthermore mentions:

> Furthermore, the BNF doesn't make it clear that request and response directives shouldn't be intermixed;
>
>     Cache-Control-v = 1#cache-directive
>
>     cache-directive = cache-request-directive
>
>         / cache-response-directive

That could be addressed by saying:

      Cache-Control-v = 1#cache-request-directive
                      / 1#cache-response-directive

However, I'm not sure we need to express this as a syntactical 
constraint (and it also might confuse people with respect to whether 
this header uses the "list style" or not).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jun 2010 17:06:49 +1000

On 02/06/2010, at 6:45 PM, Julian Reschke wrote:
> 
> Looks good to me. That being said, I rearranged the sentences and ended up with:

[snip]

Fine by me.

> However, I'm not sure we need to express this as a syntactical constraint (and it also might confuse people with respect to whether this header uses the "list style" or not).

Yes; I'm not sure we can really do anything about this, except make sure it's clear in the prose.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jun 2010 16:03:51 +0200

On 07.06.2010 14:24, Adrien de Croy wrote:
> ...
> hang on a minute. The existing BNF is logically incorrect, the proposed
> replacement is logically correct, but we worry about confusion?
> ...

Nope.

The proposed ABNF violates the syntax requirement for list-typed 
headers, at least when read literally:

"Multiple header fields with the same field name MUST NOT be sent in a 
message unless the entire field value for that header field is defined 
as a comma-separated list [i.e., #(values)]." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-09.html#rfc.section.3.2.p.6>

> I think it's more likely to create implementor confusion by having the
> ABNF disagree with the prose. It should still be clear to anyone that
> the choice is between a list of request directives or a list of response
> directives.

I think that's pretty clear already. Do we have evidence that *anybody* 
has been confused about this in the past?

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Jun 2010 13:40:26 +0200

>> Looks good to me. That being said, I rearranged the sentences and ended up with:

Ok, change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/827>.

> Yes; I'm not sure we can really do anything about this, except make sure it's clear in the prose.

Do we really need to say more than we already do?

Best regards, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 08 Jun 2010 00:24:45 +1200

Maybe the problem is that in fact the Cache-control request header is 
different to the Cache-control response header.  You shouldn't put the 
Cache-control request header in a response message and vice-versa.

Probably going to far to solve that one though, since it would require 
something like

Cache-control-v = Cache-control-req / Cache-control-resp
Cache-control-req = 1#cache-request-directive
Cache-control-resp = 1#cache-response-directive

Regards
Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com