W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: BNF for Cache-Control

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 25 May 2009 12:56:21 +1200
Message-ID: <4A19ECB5.7020601@qbik.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>

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 
>> 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
>> ...
> 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?
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.



> BR, Julian

Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 25 May 2009 00:53:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC