On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote: > Steve Downey wrote: <SNIP/> > > > > 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 Given: H:A,B H:C
getHeader() should either return ``A'' or ``A,B,C''. Returning ``A,B'', as it does now, can't be right. It introduces semantic differences between multiple headers and comma-separated lists where their must be none. The problem is that the client has no way of telling if it's supposed to use getHeader or getHeaders. Other than saying that if it's possible for there to be multiple values, you have to use getHeaders. IAC, why must getHeader return the first header line? It's documented to return 'the first head <sic> in the request', or 'a String containing the value of the requested header'. If getHeaders() returns 'all the values of the specified request header', and returns ``A'' rather than ``A,B'', then it's inconsistent for getHeader to return ``A, B''. If a servlet really wants to do the parsing itself, then getHeader only gets it part of the headers, and it has no way of getting all of the header lines, since getHeaders() doesn't do that, according to the interpretation of the spec embodied in Watchdog, the basis for the TCK. Complex and inefficient might be a reason for _changing_ the spec. It's a bad reason for not implementing the spec. Also, I don't think it's that bad. The cases where multiple values are allowed is denumerable. So it comes down to creating an enumerator that can run seamlessly over the values in distinct header lines. Now, I'll admit this is all a bit on the language-lawyerish angels-dancing-on-pins side. But this is the reference implementation, and it is currently failing the servlet test suite. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
