Hello.

I've just been bitten by the bug described previously here (http://mailman.nginx.org/pipermail/nginx/2010-September/022384.html). X-Accel-Redirect expects a decoded URL, which it will encode, but when non-ascii characters are present in the URI this process fails to produce the correct URL.

According to this 2010 thread (http://nginx.2469901.n2.nabble.com/Bug-X-Accel-Redirect-td5510716.html) the correct way to do this would be for the encoding to be done by the application, and then nginx would just use the URL in its provided form, without trying to divine the correct way to encode it.. There have been attempts to do this (http://forum.nginx.org/read.php?29,221834,221834) but they were not accepted. This one in particular tried to guess if the URL was already encoded or not.

Since I'm not familiar with nginx's code, I would like to know if it would be very hard to accomplish this task? Namely, to stop trying to encode the URL received in the X-Accel-Redirect header. It seems that I'm not alone in this and old threads exists about this issue, but since no fix was produced I'm tempted to try it myself.

Best regards,
André Cruz
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx