tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31201] - Encoding bug when using <jsp:include ...> action
Date Thu, 07 Oct 2004 21:34:00 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31201>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31201

Encoding bug when using <jsp:include ...> action





------- Additional Comments From markt@apache.org  2004-10-07 21:33 -------
I am still not happy with the portability implications of this. I still think 
it would be better for the 'fix' to be part of the application (and hence be 
portable) rather than part of the container (not portable and may require 
changes to app between containers depending on how each handles this).

That being said, if all other options are inappropriate then I am prepared to 
consider this patch. Therefore I'd would appreciate it you would consider the 
following options.

1. I understand that some developers want to include HTML directly. However, 
given that this has i18n problems and i18n is obviously important to you why 
not tell your developers that they can't do this and should convert to JSPs? 
It is a change to the file name, adding a encoding directive and changing 
references from xxx.html to xxx.jsp. This would be trivial to automate.

2. How about using -Dfile.encoding="..." at the JVM level?

3. The patch (and option 2 above) assumes that every file has the same 
encoding. Is this always the case? Might different files in different apps 
have different encodings? If so, you could specify a modified version of the 
default servlet in your web application to handle .html files. With this 
option you could even handle different static file encodings within the same 
web app. This option would give you a lot of flexibility (which may or may not 
be useful to you).

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message