You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/01/05 08:29:28 UTC

DO NOT REPLY [Bug 9526] - HttpServletRequest.getHeader(String) yields inconsistent results depending on how the request header was provided to tomcat

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526

HttpServletRequest.getHeader(String) yields inconsistent results depending on how the request header was provided to tomcat





------- Additional Comments From hoju@visi.com  2003-01-05 07:29 -------
This really needs to be fixed!  Yes, there are workarounds such as using
getHeader(headerName) and seeing if the value you are looking for exists in the
string, but this totally defeats the purpose of getHeaders(headerName).  In
addition anyone who is counting on it to work (and why shouldn't they?) and
finds it works on other servers, which are compliant with the servlet spec, will
find their code mysteriously failing because they expected a single value for
each enumerated element rather than a single enumerated element with the same
value they would get had they called getHeader(headerName).

If this won't be fixed in Tomcat 4.x.x, will it, at least, be fixed in Tomcat 5?
 It isn't fixed currently based on the testing the latest nightly buid.  I get
the same mis-behavior as in Tomcat-4.1.18.

Jake

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>