Patch for nginx handling of X-Accel-Redirect URLs

[Виталий Филиппов]

But this will basically duplicate ngx_http_parse_complex_uri's functionality in parse_unsafe_uri (at least part of it). Maybe just try to make it less "specific"? Why not have a single function for URI parsing?
-- 
Отправлено с мобильного телефона через К-9 Mail. Извините за краткость, пожалуйста.

Maxim Dounin <mdounin at mdounin.ru> написал(а):

Hello!

On Wed, Feb 01, 2012 at 03:51:18AM +0400, vitalif at yourcmc.ru wrote:

> Hello!
> 
> By now, nginx does not allow urlencoded X-Accel-Redirect URLs and
> totally fails to access files with '?' in name with it.
> The problem was also discussed at 'nginx' maillist:
> http://nginx.2469901.n2.nabble.com/Bug-X-Accel-Redirect-td5510716.html
> 
> The patch suggested there just unescaped the url in
> ngx_http_parse_unsafe_uri(). As Maxim Dounin said, this is incorrect
> because also unescapes the query string.
> I want to suggest another solution - swap
> ngx_http_parse_unsafe_uri() to ngx_http_parse_complex_uri(). The
> patch is in attachment.
> What can you say about it?

> This is a patch for nginx 1.1.12 handling of X-Accel-Redirect URLs:
> run them through ngx_http_parse_complex_uri(), not ngx_http_parse_unsafe_uri().
> It allows to handle percent-encoded URLs and complex filenames in X-Accel-Redirect
> (for example, filenames which contain '?').

I don't think that swap with ngx_http_parse_complex_uri() is a 
good idea. It's very specialized function to parse original 
request uri, and in particular it modifies many private request 
fields which shouldn't be modified by proxy.

I would rather like to see ngx_http_parse_unsafe_uri() changes 
done right (i.e. unescape only uri, but not query string, and 
preserve checks currently done).

Note that among standard modules the change of 
ngx_http_parse_unsafe_uri() will also affect dav and ssi modules. 
I think that in both cases effect will be similar to one with 
X-Accel-Redirect, i.e. positive (though I haven't checked too 
deep).

Maxim Dounin

_____________________________________________

nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120201/7ee3c542/attachment.html>