nginx 400 error when username included in the uri
michaelc at wush.net
Wed Aug 20 04:35:52 MSD 2008
Currently when nginx encounters a Request-URI of the form
http://email@example.com/ it returns error 400. This appears to be
proper per RFC 2616 since the username@ is not recognized by the RFC for
HTTP URIs. However, this is causing problems for us when dealing with
some clients because Apache silently discards the username:password@
portion of the URI. Users with clients expecting to see the same
behavior (e.g. Apple's XCode) receive an error instead.
We realize that accepting this would be non-standard behavior and
understand if incorporating the changes is not possible. However, it
would be useful to us if we could have the option to let nginx be as
permissive as Apache while proxying to it. Either way, we would
appreciate any feedback on the patch in terms unintended side-effects, etc.
Something like the following should allow nginx to ignore the
*** nginx-0.6.32/src/http/ngx_http_parse.c 2008-03-16
--- nginx-0.6.32-new/src/http/ngx_http_parse.c 2008-08-19
*** 355,360 ****
--- 355,363 ----
r->uri_end = r->schema_end + 2;
state = sw_http_09;
+ case '@':
+ r->host_start = p + 1;
For reference, in APR's apr_uri_parse method used by Apache, it
information is silently discarded from what I can tell:
/* If there's a username:password at host:port, the @ we want is the last @...
* too bad there's no memrchr()... For the C purists, note that hostinfo
* is definately not the first character of the original uri so therefore
* &hostinfo[-1] < &hostinfo ... and this loop is valid C.
} while (s >= hostinfo && *s != '@');
More information about the nginx