<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
&nbsp;<BR>

&gt; Date: Thu, 21 Oct 2010 11:29:24 +0400<BR>&gt; From: mdounin@mdounin.ru<BR>&gt; To: nginx@nginx.org<BR>&gt; Subject: Re: nginx doesn't handle different URL encodings well<BR>&gt; <BR>&gt; Hello!<BR>&gt; <BR>&gt; On Thu, Oct 21, 2010 at 03:23:46AM +0200, Pierre-Marie Baty wrote:<BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; Hello Igor, hello all,<BR>&gt; &gt; <BR>&gt; &gt; Congratulations for your fantastic and neatly programmed web <BR>&gt; &gt; server. It's a pleasure to use it.<BR>&gt; &gt; <BR>&gt; &gt; I have a problem with nginx not serving files with accentuated <BR>&gt; &gt; characters when the sumbitted URL is UTF-8 encoded.<BR>&gt; &gt; <BR>&gt; &gt; Here is my nginx.conf : http://nginx.pastebin.com/aB7XRLM3 It's <BR>&gt; &gt; a home webserver that is primarily used to serve stuff like <BR>&gt; &gt; holiday photos.<BR>&gt; &gt; <BR>&gt; &gt; For example, I have a file called "été-2008.jpg" on my <BR>&gt; &gt; webserver. When I request http://myserver/été-2008.jpg, <BR>&gt; &gt; depending on whether the "Always send URLs as UTF-8" checkbox is <BR>&gt; &gt; checked or not in the Internet Explorer advanced options, the <BR>&gt; &gt; file is correctly served, or not.<BR>&gt; &gt; <BR>&gt; &gt; When the URL is Latin-1 encoded, the request sent is : GET <BR>&gt; &gt; /%e9t%e9-2008.jpg ----&gt; nginx resolves this to "été-2008.jpg", <BR>&gt; &gt; the file is served, OK<BR>&gt; &gt; When the URL is UTF-8 encoded, the request sent is : GET <BR>&gt; &gt; /%C3%A9t%C3%A9-2008.jpg ----&gt; nginx resolves this to <BR>&gt; &gt; "été-2008.jpg", and the file is not served. (file not found)<BR>&gt; &gt;<BR>&gt; &gt; Shouldn't a fallback mechanism be implemented so that when a <BR>&gt; &gt; file isn't found after an URL has been decoded, a second try is <BR>&gt; &gt; made with another encoding ? I believe two RFCs are involved : <BR>&gt; &gt; rfc2396 and rfc3986 (info given by PiotrSikora on IRC). IMO, <BR>&gt; &gt; nginx shouldn't assume the URL it gets are always following the <BR>&gt; &gt; same RFC. From what I know, this ambiguity is resolved in <BR>&gt; &gt; Apache. Maybe they have that sort of fallback mechanism.<BR>&gt; <BR>&gt; The only (related to the question) difference between RFC2396 and <BR>&gt; RFC3986 is that later one recommends using UTF-8 for new URI <BR>&gt; schemes. There is no ambiguity between the two: character set for <BR>&gt; non-US-ASCII characters in http URLs isn't defined (though most <BR>&gt; browsers nowadays use UTF-8 by default).<BR>&gt; <BR>&gt; The only solution is to provide correct URLs, i.e. already <BR>&gt; encoded ones.<BR>&gt; <BR>&gt; If you think that "fallback mechanism" is a good idea - you may <BR>&gt; implement one with "try_files" directive and embedded perl module <BR>&gt; to do recoding between Latin1 and UTF-8. Note though that this <BR>&gt; may lead to unexpected results: "/%C3%A9" may be Latin1 "/é" as <BR>&gt; well as UTF-8 "/é".<BR><BR>
Yes, it makes sense. But shouldn't nginx assume a UTF-8 encoding&nbsp;instead of&nbsp;assuming a Latin-1 one ? Since in the future all URI will adopt this encoding method.&nbsp;IMO a&nbsp;request like GET /%C3A9t%C3A9-2008.jpg should translate to /été-2008.jpg - and not the other way around, like it's the case currently.<BR>
&nbsp;<BR>
Currently nginx assumes URLs are encoded in&nbsp;Latin1, whereas it should assume they're UTF-8 first. Don't you think ?<BR>
&nbsp;<BR>
-- <BR>
Pierre-Marie Baty<BR>                                               </body>
</html>