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 20361] New: - Redirection responses sent on localized OS for Japanese and French are improperly formatted
Date Fri, 30 May 2003 17:09:19 GMT
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=20361>.
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=20361

Redirection responses sent on localized OS for Japanese and French are improperly formatted

           Summary: Redirection responses sent on localized OS for Japanese
                    and French are improperly formatted
           Product: Tomcat 3
           Version: 3.3.1 Final
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: gbraven@yahoo.com


When performing a redirection response

 response.sendRedirect(response.encodeRedirectURL(<myurl>));

in a Tomcat instance running on a localized Japanese or French OS the 
redirection response sent to the browser can be incorrectly encoded or have the 
encoding misidentified.

The Tomcat ErrorHandler class explicitly sets the ContentType to be "text/html" 
for redirections.  This causes the ContentType header to be "text/html".  
However the response itself can contain multibyte data taken from the Japanese 
and French resource files distibuted with Tomcat.  The following section of 
code shows how these resource files are used to construct a response based upon 
the default locale of the JVM:

>From ErrorHandler.java

	res.setContentType("text/html");	// ISO-8859-1 default
	res.setHeader("Location", location);

	if( sbNote==0 ) {
	    sbNote=req.getContextManager().getNoteId
(ContextManager.REQUEST_NOTE,
						     "RedirectHandler.buff");
	}

	// we can recycle it because
	// we don't call toString();
	StringBuffer buf=(StringBuffer)req.getNote( sbNote );
	if( buf==null ) {
	    buf = new StringBuffer();
	    req.setNote( sbNote, buf );
	}
	buf.append("<html><head><title>").
	    append(sm.getString("defaulterrorpage.documentmoved")).
	    append("</title></head>\r\n<body><h1>").
	    append(sm.getString("defaulterrorpage.documentmoved")).
	    append("</h1>\r\n").
	    append(sm.getString("defaulterrorpage.thisdocumenthasmoved")).
	    append(" <a href=\"").
	    append( HttpMessages.filter( location ) ).
	    append("\">here</a>.<p>\r\n</body>\r\n</html>");

	res.setContentLength(buf.length());
	res.getBuffer().write( buf );
        res.getBuffer().close();
	buf.setLength(0);

If the encoding has been specified earlier in the JSP using a page directive:

<%@page contentType="text/html; charset=utf-8"%>

the encoding of the redirection response will be the charset specified in the 
page directive even though the response header indicates otherwise.  On some 
browsers this disagreement between specified encoding and actual encoding can 
cause the browser to hang and not be redirected (seen on IE 6 - strangely only 
when the redirection url is sufficiently long).

---------------------------------------------------------------------
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