<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Hello Igor, hello all,<BR>
<BR>
Congratulations for your fantastic and neatly programmed web server. It's a pleasure to use it.<BR>
<BR>
I have a problem with nginx not serving files with accentuated characters when the sumbitted URL is UTF-8 encoded.<BR>
<BR>
Here is my nginx.conf : <A href="http://nginx.pastebin.com/aB7XRLM3">http://nginx.pastebin.com/aB7XRLM3</A> It's a home webserver that is primarily used to serve stuff like holiday photos.<BR>
<BR>
For example, I have a file called "été-2008.jpg" on my webserver. When I request <A href="http://myserver/été-2008.jpg">http://myserver/été-2008.jpg</A>, depending on whether the "Always send URLs as UTF-8" checkbox is checked or not in the Internet Explorer advanced options, the file is correctly served, or not.<BR>
<BR>
When the URL is Latin-1 encoded, the request sent is : GET /%e9t%e9-2008.jpg ----> nginx resolves this to "été-2008.jpg", the file is served, OK<BR>
When the URL is UTF-8 encoded, the request sent is : GET /%C3%A9t%C3%A9-2008.jpg ----> nginx resolves this to "été-2008.jpg", and the file is not served. (file not found)<BR>
<BR>
Shouldn't a fallback mechanism be implemented so that when a file isn't found after an URL has been decoded, a second try is made with another encoding ? I believe two RFCs are involved : rfc2396 and rfc3986 (info given by PiotrSikora on IRC). IMO, nginx shouldn't assume the URL it gets are always following the same RFC. From what I know, this ambiguity is resolved in Apache. Maybe they have that sort of fallback mechanism.<BR>
<BR>
Thanks to the IRC channel members who pointed me towards this mailing list. I look forward for your reply in order to know what to do :)<BR>
<BR>
Spassiba !<BR>
<BR>
-- <BR>
Pierre-Marie Baty<BR>
<BR> </body>
</html>