Opened 7 years ago
Closed 22 months ago
#882 closed defect (fixed)
Unencoded Location: header when redirecting
|Reported by:||stackoverflow.com/users/32168/jim-nelson||Owned by:|
|nginx -V:||nginx/1.4.6 (Ubuntu)|
As posted on the mailing list (http://mailman.nginx.org/pipermail/nginx/2016-January/049650.html):
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? in trunk) and not from our rewrite rules. As I read the HTTP spec, Location: must be encoded.
Change History (4)
comment:1 by , 7 years ago
|Status:||new → accepted|
comment:2 by , 23 months ago
comment:4 by , 22 months ago
|Status:||accepted → closed|
Note: See TracTickets for help on using tickets.
See also #2016.