Opened 10 years ago
Closed 10 years ago
#527 closed defect (invalid)
"+" sign is encoded by rewrite as %2B
| Reported by: | Artiom Molchanov | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | nginx-module | Version: | 1.4.x |
| Keywords: | rewrite encoding plus space | Cc: | |
| uname -a: | FreeBSD pluton 9.2-RELEASE-p3 FreeBSD 9.2-RELEASE-p3 #8: Thu Feb 27 20:21:59 CET 2014 boss@pluton:/usr/obj/usr/src/sys/PLUTON i386 | ||
| nginx -V: |
nginx version: nginx/1.4.7
TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_dav_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_stub_status_module --with-pcre --with-http_spdy_module --with-http_ssl_module |
||
Description
When I use regular expression in Nginx’s rewrite rules, it will try to encode the matches in the replacement URL. For example, if orignal URL contains “Hosting Fu”, il will generate the following request:
GET /search/node/Hosting+Fu HTTP/1.1
However, Nginx with a rule :
rewrite /(.*)$ /index.php?q=$1 last;
will rewrite that to:
GET /index.php?q=search/node/Hosting%2BFu HTTP/1.1
Note it encoded ‘+’ to ‘%2B’, which confuses script. In case of Apache, ‘+’ passed through rewrite rules untouched.
Change History (2)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Current behaviour is correct, as '+' has special meaning in query string, but not in path. A solution to ticket #52 should make things more flexible.
In this particular case, I would recommend using something like
location / {
fastcgi_pass ...
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param QUERY_STRING $request_uri;
...
}
instead of using rewrites.
I would mention also the ticket http://trac.nginx.org/nginx/ticket/52
I think the best solution would be an option for rewrite statement to stop encoding at all. like no_url_encoding for no encoding at all and force_url_encoding for encoding any character not acceptable in URL, like space, & etc.