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. 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
