This has been discussed on tomcat-dev pretty thoroughly
already.  Tomcat 4.1.27 and earlier were hard coded to
use UTF-8 for decoding URLs.  This allowed you to easily
develop a dependency on this "feature" and then later
discover your webapp isn't portable.  Tomcat 4.1.30 and
5.0.19 fix this by forcing you to change the default,
which supports portability, to something that does not.
Hence, no surprises with respect to portability.

Note that URL query string encoding is affected by the
useBodyEncodingForURI attribute.  Tomcat 4.1.30 defaults
this to true, to maintain the same behavior as prior
Tomcat 4.1.x versions. In Tomcat 5.0.19 it defaults to
false.  If you try to serve some webapps that aren't
using UTF-8 everywhere, you could be impacted by this.

Cheers,
Larry

> -----Original Message-----
> From: Edward Toro [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 11, 2004 12:58 PM
> To: Tomcat Users List
> Subject: RE: international filenames inaccessible
> 
> 
> Wow, that worked!
> 
> The problem may actually be in Java rather than Tomcat.  I 
> set the DEBUG value to 1001 on a 5 server and a 4.1.18 server 
> to check the request info.  The call to getServletPath() 
> returns a different value between 4.1.18 and the latest 
> releases.  I suppose previously Java did the decoding, but 
> now the servlet is responsible for the decoding?  Or maybe 
> the newer servers specify ISO-8859-1 instead of letting Java 
> do the work?
> 
> It's really annoying that this value overrides the use of the 
> "file.encoding" System property.  A previous "solution" 
> mentioned using that, but I couldn't get it to work.
> 
> IMO, the server should be able to serve files with 
> international file names without any extra configuration, 
> especially since it used to do it before.  UTF-8 is becoming 
> the standard for international character transmission over 
> the net, if it's not the standard already.  And UTF-8 looks 
> exactly like ASCII for all the values in the ASCII range.  Is 
> this something worth bringing up in the Tomcat-Dev group?
> 
> -ET
> 
> -----Original Message-----
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 11, 2004 12:36 PM
> To: Tomcat Users List
> Subject: RE: international filenames inaccessible
> 
> 
> See the "uriEncoding" attribute described at:
> 
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/http.html
> 
> The same attribute applies to Tomcat 4.1.30 as well.
> 
> I'm not aware of any specs that guarantee behavior when using
> non-ASCII characters in the URL in this fashion, but it might
> work.
> 
> Cheers,
> Larry
> 
> > -----Original Message-----
> > From: Edward Toro [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, March 11, 2004 11:10 AM
> > To: Tomcat Users List
> > Subject: international filenames inaccessible
> > 
> > 
> > Does anyone know if Tomcat 5 is supposed to serve files with 
> > international characters in their filenames?  It used to work 
> > in Tomcat 4.1.24, but stopped working in 4.1.30 and doesn't 
> > work in 5.0.19.
> > 
> > In all the versions of Tomcat I've seen, the international 
> > characters are converted using URLEncoder(filename, "UTF-8") 
> > as per the standard at 
> > http://www.w3.org/International/O-URL-> code.html.  But the 
> > broken servers return 404 when you try 
> > to access international filenames like that.
> > 
> > The code to interpret the encoding is provided on that w3.org 
> > page.  Why isn't it part of the server anymore?
> > 
> > -Ed
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to