benoitc/gunicorn — Issue #297: Incorrectly parsing certain forms of relative URIs
Author: mikepk
Created: 2012-02-01 20:19:25+00:00
State: open

We're using gunicorn in a production environment and ran across an interesting issue.

Some of the 'script kiddie' attacks on our host were including requests to the URI `//index.php`. This was causing our WSGI routing layer to complain because PATH_INFO was being left blank. Upon further investiagtion it looks like [gunicorn is using urlparse from the standard library](https://github.com/benoitc/gunicorn/blob/master/gunicorn/http/message.py#L158) to parse the request URI.

The [urlparse module](http://docs.python.org/library/urlparse.html#urlparse.urlparse) interprets `//index.php` as a form of relative URI that includes a net location and leaves the path and PATH_INFO blank. I can put a catch in our code for blank PATH_INFO but I think the parsing of this form of relative URI is actually incorrect.

After some discussion this seems to be in violation of the HTTP spec [rfc2616](http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2):

>5.1.2 Request-URI
>The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
>	Request-URI = "*" | absoluteURI | abs_path | authority

So it seems that while the URI spec [rfc2396](http://www.ietf.org/rfc/rfc2396.txt) allows for a relative URI pattern of //net_path (or net location), the HTTP RFC seems to exclude it in what's alloweds as a relative URI in a Request-URI. It seems to only allow abs_path as the relative form in HTTP request URIs.

In that case `//index.php` should still be interpreted as an absolute path in the HTTP request.