Re: NULL paths in requests

On Jul 3, 2009, at 8:23 PM, Adrien de Croy wrote:

> I've found a client that sends requests (when configured to use a  
> proxy) like:
>
> GET  HTTP/1.1
> Host: some host
>
> e.g. 2 spaces between GET and HTTP/1.1
>
> Is this deemed a "NULL" path?

No, it is just a broken request.  Respond with 400 or 404, depending on
whether you want to interpret it as a 1.1 request or 0.9 request.

> In httpbis-p1-messaging-06.txt it talks about
>
>  A transparent proxy MUST NOT rewrite the "path-absolute" part of the
>   received request-target when forwarding it to the next inbound
>   server, except as noted above to replace a null path-absolute with
>   "/".
>
>
> However this doesn't make much sense, since what is a transparent  
> proxy?

It is defined in the spec.

> Is this one that intercepted the TCP connection?

No. It is a proxy that is not designed to transform requests or  
responses
to something other than was requested/responded.

> Otherwise it should have received a request in the form absolute- 
> URI, which isn't allowed to be rewritten as above.  Or is it?

It must be rewritten when a request is forwarded to an origin server.
The above is specifically talking about the path part.

> In fact path-absolute isn't necessarily a part of the request-URI,  
> it could be the whole request-URI.

Not on a request to a proxy.

> Actually absolute-URI as per RFC 3986 seems to allow a lot more  
> forms than it did in RFC2616.  Is this desired?  I'd presume not.
>
> from RFC 3986
>
>   absolute-URI  = scheme ":" hier-part [ "?" query ]
>
>   hier-part     = "//" authority path-abempty
>                 / path-absolute
>                 / path-rootless
>                 / path-empty
>
>
> e.g. in the old form, the path-absolute, path-rootless, and path- 
> empty forms were not allowed as part of absolute-URI.

Please read the ABNF from left to right.

....Roy

Received on Saturday, 4 July 2009 14:15:06 UTC