Steve Downey wrote: > On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote: > >>Steve Downey wrote: >> >>>On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote: >>> >>>>Patrick Luby wrote: >>>> >>>>>Steve, >>>>> >>>>>Your assessment is correct: an aggregate header like: >>>>> >>>>> header1: val1, val2 >>>>> >>>>>should be converted to this for the HttpRequest: >>>>> >>>>> header1: val1 >>>>> header1: val2 >>>> >>>>No, this is not correct. >>>> >>>>You are allowed to do that only if the application knows it makes sense >>>>to do so (ie, only when it call getHeaders). >>> >>>If it is to be done, it should be done based on what the HTTP/1.1 spec >>>defines. The application needs to expect the possibility of multiple >>>values for all of the headers that allow them. Or just ask for the first >>>one. Parsing the header line into values probably shouldn't be left to >>>the application, although it is at the moment. >> >>I gave you the HTTP/1.1 answer. >> >>For Header H: A,B >>If A,B >>is semantically equivalent to: >>H: A >>H: B >>then you can parse for the comma. >> >>So since you can't know what the application considers to be >>semantically equivalent, the fact that it calls getHeaders is a big >>hint, and you can do the comma parsing. >> >>Please read the HTTP specification. >> > > > I keep a copy handy, for just such an occasion. However, my reading is someone > different from yours. I think this is the relevant section [RFC 2616, > section 4.2], that describes what happens when multiple headers are sent: > > Multiple message-header fields with the same field-name MAY be > present in a message if and only if the entire field-value for that > header field is defined as a comma-separated list [i.e., #(values)]. > It MUST be possible to combine the multiple header fields into one > "field-name: field-value" pair, without changing the semantics of the > message, by appending each subsequent field-value to the first, each > separated by a comma. The order in which header fields with the same > field-name are received is therefore significant to the > interpretation of the combined field value, and thus a proxy MUST NOT > change the order of these field values when a message is forwarded. > > So it's saying the opposite: > H:A > H:B > > MUST be semantically equivalent to > H:A,B > > as long as H is defined to have be a comma separated list. If it doesn't, it > seems the result is undefined.
I agree up until now. > Now, the spec refers to not changing the semantics, but the MUST means that it > is a requirement for the implementation. In other words, if combining the two > headers into one comma separated list, for headers with a #(values) content > model, changes the semantics, the implementation is non-conformant. The > specification does not require that the implementation guess at the semantics > an application believes apply, the specification defines the semantics that > will apply. > > The real problem, for the servlet spec implementation, is that not just > getHeaders() is affected. getHeader() must be also. getHeader, if there are > multiple values, needs to return the same thing as the first value returned > by getHeaders(), not the whole header from the first of multiple headers. Sorry, but no. The opposite statement doesn't work. getHeader MUST return the first header line, unless in the case there are multiple headers with the same name in the client message, in which case you would know that they can be parsed/combined at will. Since it is too complex and inefficient to implement that, I'd leave it at that, and let the application handle the cases where the client is having some fun. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
