Problem with filename encoding

[Igor Sysoev]

On Nov 13, 2012, at 12:41 , Nilshar wrote:

> On 13 November 2012 09:38, Igor Sysoev <igor at sysoev.ru> wrote:
> On Nov 13, 2012, at 12:32 , Nilshar wrote:
> 
>> Hello list,
>> 
>> I got an issue with a filename containing "strange" characters.
>> It seems that nginx is not able to url_decode correctly, and then get the right file.
>> 
>> Yes, the filename is ugly : "Capture d’écran 2010-09-25 à 08.30.07.png"
>> but apache is able to read it, and nginx is not :
>> 
>> nginx strace :
>> open("/<path>/images/Capture%20d%E2%80%99%C3%A9cran%202010-09-25%20%C3%A0%2008.30.07.png", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
>> 
>> apache strace :
>> open("/<path>/images/Capture d\342\200\231\303\251cran 2010-09-25 \303\240 08.30.07.png", O_RDONLY|O_CLOEXEC) = 100
>> 
>> So it seems that nginx is using the url_encoded version of the filename, while apache do it's own thing on it.
>> 
>> On both apache and nginx, the access log says : "GET /images/Capture%20d%E2%80%99%C3%A9cran%202010-09-25%20%C3%A0%2008.30.07.png"
>> 
>> both server have the same locales settings, and I tried different charset configuration into nginx, but no luck..
>> 
>> Any idea how I can fix that without changing the filename (sadly, it's not possible :/) ?
> 
> 
> The most probably there is a rewrite in configuration which changes URI to $request_uri.
> nginx escapes URI if no one interferes.
> 
> 
> Yes indeed, there is a rewrite !
> got a tip on how to fix that ?


The general rule is to not use rewrites at all: they make configuration to a mess.


--
Igor Sysoev
http://nginx.com/support.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20121113/7856ac33/attachment.html>