Steve Downey wrote: > 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.
Yes, it is right. Consider: H: A, B In that case, getHeader() has to return "A, B" since it is not known if this header is comma separated, as per the spec definition. In the case: H: A, B H: C Well, you have multiple choices, all of which are valid. - you may want to return the same thing as above, which means you return "A, B" - you can also return "A" Returning "A, B, C" is incorrect, as you have to return the first value of the header. Since implementing the first option is easier, I'd leave the current behavior. getHeaders indicate that the header is comma separated, so it should be parsed. This is not currently done, but indeed it should be done. Hacking MimeHeaders can result in a correct *and* efficient implementation. > 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''. Sorry, but no. To parse the comma delimited string, you have to know that the header complies with the HTTP spec definition of a comma parsable header. Only the application knows that. > 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. (I'm getting tired of it, sorry, so this is likely my last email of the thread) +1 for fixing getHeaders (in an efficient way, as it appears there's one) -1 for changing getHeader behavior, as none is "more correct" than the other A small precision: Tomcat IS NOT the reference implementation of anything. The codebase only happens to be used by Sun to make the J2EE reference implementation. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
