nginx 400 error when username included in the uri

[Michael Ching]

Hello,

Currently when nginx encounters a Request-URI of the form 
http://username@host.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 
username:password:

*** nginx-0.6.32/src/http/ngx_http_parse.c      2008-03-16 
11:47:16.000000000 -0500
--- nginx-0.6.32-new/src/http/ngx_http_parse.c  2008-08-19 
13:07:50.000000000 -0500
***************
*** 355,360 ****
--- 355,363 ----
                  r->uri_end = r->schema_end + 2;
                  state = sw_http_09;
                  break;
+             case '@':
+                 r->host_start = p + 1;
+                 break;
              default:
                  return NGX_HTTP_PARSE_INVALID_REQUEST;
              }


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[0] ... and this loop is valid C.
*/
do {
--s;
} while (s >= hostinfo && *s != '@');


Thank you,
Michael Ching