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/04/22 16:11:04 UTC
DO NOT REPLY [Bug 7602] -
After RequestDispatcher.forward() the character encoding for parameters is set to ISO-8859-1
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=7602>.
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=7602
After RequestDispatcher.forward() the character encoding for parameters is set to ISO-8859-1
remm@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From remm@apache.org 2003-04-22 14:11 -------
With the current state of i18n in HTTP and the servlet specification, I don't
agree that this is really a bug. i18n can't really work with parameters in RD as
they are currently specified (and IMO they shouldn't exist in the first place,
as the implementation is by definition extremely inefficient; don't use it !!).
In Tomcat 5, (as an experiment, it may change if people complain) the URL will
be processed according to the encoding specified in the connector. As an option,
it could also use the request content type, but I have to point out that the
HTTP spec says that the content type only applies to the entity body (= not the
HTTP header).
If you want to really control how things are parsed, you should read the request
content before using getParameters (note that i18n will work fine and is well
specified for POSTed content).
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org