We’re seeing the following behavior in nginx 1.4.6:
* User navigates to location w/ spaces in the URL
("http://example.org/When%20Harry%20Met%20Sally";). The location points to a
directory on the filesystem with spaces in its name ("/items/When Harry Met
Sally”).
* nginx returns “301 Moved Permanently” with the Location: URL unencoded and a
trailing slash added:
Location: http://example.org/When Harry Met Sally/
* Some software (i.e. PHP) will automatically follow the redirect, but because
it expects an encoded Location: header, it sends exactly what was returned from
the server. (Note that curl, wget, and others will fixup unencoded Location:
headers, but that’s not what HTTP spec requires.)
* nginx will normally process URLs with spaces in them, but because of its
request parsing algorithm, it fails w/ a “400 Bad Request” when it sees the
uppercase ‘H’ in “Harry” in the URL
(https://trac.nginx.org/nginx/ticket/196?cversion=0&cnum_hist=2).
In other words, this is the transaction chain:
C: GET http://example.org/When%20Harry%20Met%20Sally HTTP/1.1
S: HTTP/1.1 301 Moved Permanently
S: Location: http://example.org/When Harry Met Sally/
C: GET http://example.org/When Harry Met Sally/ HTTP/1.1
S: 400 Bad Request
I believe the 301 originates from within the nginx code itself
(ngx_http_static_module.c:147-193?) and not from our rewrite rules. As I read
the HTTP spec, Location: must be encoded.
— Jim
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
