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.comReceived on Monday, 25 May 2009 07:29:21 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC