- From: Adrien de Croy <adrien@qbik.com>
- Date: Mon, 25 May 2009 19:31:55 +1200
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Julian Reschke wrote: > Adrien de Croy wrote: >> 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). > > In case you didn't notice: those have been separated into distinct > subsections since draft 05. 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. > > The descriptions already should clearly say "general", "request", > "response", or "entity"... 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 -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 25 May 2009 07:29:21 UTC