#262 closed defect (invalid)
Unescaped characters in URI passed to target server
Reported by: | Tomasz Nurkiewicz | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-core | Version: | 1.1.x |
Keywords: | Cc: | ||
uname -a: | Linux tomasz-VirtualBox 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.1.19
TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-dav-ext-module |
Description
When I browse to this URL: http://localhost:8080/foo/%5B-%5D
server (nc -l 8080
) receives it as-is:
GET /foo/%5B-%5D HTTP/1.1
However when I proxy this application via nginx:
location /foo { proxy_pass http://localhost:8080/foo; }
The same request routed through nginx port is forwarded with path decoded:
GET /foo/[-] HTTP/1.1
Decoded square brackets in the GET path are causing the errors in the target server (HTTP Status 400 - Illegal character in path...) as they arrive un-escaped.
This results in an application failing to work via nginx (as it received malformed URI) while it works perfectly fine when called directly. Not sure, but it makes me believe such behavior of nginx is a bug, not a feature.
Reference: Disabling URL decoding in nginx proxy
A quote from documentation:
The correct configuration in your case would be: