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>