Subject: BNF for Cache-Control

From: Adrien de Croy <[email-masked]>
Date: Sun, 24 May 2009 15:17:00 +1200

the production for Cache-control seems to imply that any cache control 
header can contain any number of cache-request-directive or 
cache-response-directive.  This means a mixture of both is permissible.

    Cache-Control = "Cache-Control" ":" 1#cache-directive
    cache-directive = cache-request-directive | cache-response-directive

Is this intended?  Surely cache-response-directive are only valid for 
responses, and cache-request-directive for requests?

I would have expected something more like:

    Cache-Control = "Cache-Control" ":" cache-control-request | 
cache-control-response
    cache-control-request = 1#cache-request-directive
    cache-control-response = 1#cache-response-directive

to enforce separation.

Apologies if this is already covered in HTTPbis

Regards

Adrien

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 24 May 2009 11:23:10 +0200

Adrien de Croy wrote:
> ...

There's a limit to what we can (or *want*) express in the ABNF.

If we made that change, a header instance that combined both request and 
response directives would by syntactically invalid. Would that reflect 
what's really desired and implemented? Shouldn't recipients just ignore 
those directives they don't understand?

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 24 May 2009 05:11:15 -0500

Julian Reschke wrote:
> If we made that change, a header instance that combined both request
> and response directives would by syntactically invalid. Would that
> reflect what's really desired and implemented? Shouldn't recipients
> just ignore those directives they don't understand?

A parser using the current grammar will never recognize anything as a
cache-response-directive, because cache-response-directive comes after
cache-request-directive, and cache-request-directive matches all
cache-response-directives, because of its cache-extension alternative. (The
RFC3986 grammar uses a "first-match-wins" parsing rule. Since the HTTP
grammar reuses some of these "first-match-wins" productions, I'm assuming
that the HTTP grammar also requires "first-match-wins" parsing throughout.
Otherwise, it would be ambiguous in at least a few places.)

A grammar like Adrien's suggested is definitely clearer than the current
one. The specification would be even clearer (and, importantly, without
grammar ambiguity) if it treated Cache-Control as separate request- and
response- headers, instead of a single header with two different syntaxes.
That is probably something best looked at after the grammar changes in the
way Julian mentioned a few days ago (looking up the syntax based on the name
of the header).

- Brian

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 25 May 2009 12:56:21 +1200

Julian Reschke wrote:
> Adrien de Croy wrote:
>>
>> the production for Cache-control seems to imply that any cache 
>> control header can contain any number of cache-request-directive or 
I guess the answer lies in the wording around the directives 
themselves.  Some of them it's pretty clear are intended only for 
request messages, some for response messages.  Some are less clear, and 
the syntax for some differs between request and response (e.g no-cache).

So one way to look at this would be that the grouping of directives into 
cache-request-directive and cache-response-directive are mainly to 
demonstrate which type of messages these directives are expected to be 
used in, without banning them from the other.

I guess a similar issue would arise in any header that could be part of 
a request or response message which contains directives which may or may 
not make sense for a request or a response (e.g. Connect).

In the end, I'm more than happy to ignore headers that don't make sense 
in the context, but specific wording in the spec to back those decisions 
up would be useful.

Cheers

Adrien

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 May 2009 08:56:09 +0200

> the syntax for some differs between request and response (e.g no-cache).

In case you didn't notice: those have been separated into distinct 
subsections since draft 05.

> in the context, but specific wording in the spec to back those decisions 

The descriptions already should clearly say "general", "request", 
"response", or "entity"...

Do you think that is not sufficient? Maybe you could clarify, based on a 
concrete example?

BR, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 25 May 2009 19:31:55 +1200

Julian Reschke wrote:
>> request messages, some for response messages.  Some are less clear, 
>> and the syntax for some differs between request and response (e.g 
>> no-cache).
>
you referring to the HTTPbis work?  I've been referring to RFC2616.

>
>> So one way to look at this would be that the grouping of directives 
>> into cache-request-directive and cache-response-directive are mainly 
>> to demonstrate which type of messages these directives are expected 
>> to be used in, without banning them from the other.
>>
>> I guess a similar issue would arise in any header that could be part 
>> of a request or response message which contains directives which may 
>> or may not make sense for a request or a response (e.g. Connect).
>>
>> In the end, I'm more than happy to ignore headers that don't make 
>> sense in the context, but specific wording in the spec to back those 
>> decisions up would be useful.
>

sorry, I meant ignore cache directives (not headers) that don't make 
sense in the context - as you were suggesting.  I just didn't want to 
create problems in case some server sent some directive that looked like 
a request directive, and I'd predetermined to ignore it.

Regards

Adrien

>
> Do you think that is not sufficient? Maybe you could clarify, based on 
> a concrete example?
>
> BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 May 2009 13:42:17 +0200

> you referring to the HTTPbis work?  I've been referring to RFC2616.

Yes. So how is RFC2616 relevant anymore, if we have already done what 
you asked for?

Me confused...

Best regards, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 26 May 2009 08:28:50 +1200

Sorry, I hadn't reviewed the HTTPbis work.  So at that stage the 
question was more to the point of is it acceptable to mix the directives 
or not, and whether that was intended.

If it's covered in HTTPbis, then my question is answered, I have looked 
through HTTPBis, but it's still not quite at a stage to use it for 
implementation (lots of outstanding To-dos in there), so I didn't go 
through the Cache-Control sections.

Thanks

Adrien