# X-Accel-Redirect and encodings

**URL:** <https://www.ruby-forum.com/t/x-accel-redirect-and-encodings/229299>\
**Category:** NGINX\
**Created:** [January 25, 2013, 5:18pm UTC](https://www.ruby-forum.com/t/x-accel-redirect-and-encodings/229299 "2013-01-25T17:18:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![SSAndrSS\_CruzSS\_SSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c5a1d2/32.png) [@SSAndrSS\_CruzSS\_SSS](https://www.ruby-forum.com/u/SSAndrSS_CruzSS_SSS)\
**Post date:** [January 25, 2013, 5:18pm UTC](https://www.ruby-forum.com/t/x-accel-redirect-and-encodings/229299/1 "2013-01-25T17:18:32Z")

</div>

Hello.

I’ve just been bitten by the bug described previously here  
([X-Accel-Redirect doesn't URL-decode paths](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](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 ([Patch for nginx handling of X-Accel-Redirect URLs](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