- From: Adrien de Croy <adrien@qbik.com>
- Date: Mon, 25 May 2009 12:56:21 +1200
- 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. Cheers Adrien > BR, Julian > > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 25 May 2009 00:53:45 UTC