Subject: NULL paths in requests

From: Adrien de Croy <[email-masked]>
Date: Sat, 04 Jul 2009 15:23:29 +1200

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?  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?  Is this one that intercepted the TCP connection?  Otherwise it 
should have received a request in the form absolute-URI, which isn't 
allowed to be rewritten as above.  Or is it?

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

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.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 4 Jul 2009 07:14:31 -0700

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
>
> 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
>
> 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
>
> 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

---

From: Adrien de Croy <[email-masked]>
Date: Sun, 05 Jul 2009 12:07:40 +1200

> whether you want to interpret it as a 1.1 request or 0.9 request.
turns out this was coming out the other side of a proxy, and what was 
going in was a absolute-URI missing a final '/'

In which case I think a proxy is allowed to add it back in.

>> However this doesn't make much sense, since what is a transparent proxy?
>
> No. It is a proxy that is not designed to transform requests or responses
>> Otherwise it should have received a request in the form absolute-URI, 
>> which isn't allowed to be rewritten as above.  Or is it?
>
>> e.g. in the old form, the path-absolute, path-rootless, and 
>> path-empty forms were not allowed as part of absolute-URI.
>
you mean I should read it as

hier-part = "//" authority (path-abempty / path-absolute / path-rootless 
/ path-empty)

rather than

hier-part = ( "//" authority path-abempty) / (path-absolute) / 
(path-rootless) / (path-empty)

?

Thanks

Adrien

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 5 Jul 2009 14:36:54 -0700

On Jul 4, 2009, at 5:07 PM, Adrien de Croy wrote:
> hier-part = "//" authority (path-abempty / path-absolute / path- 
> rootless / path-empty)
>
> rather than
>

No, I mean you should read it as

which clearly shows the scheme and colon before hier-part.
hier-part [ "?" query ] is syntactically equivalent to *uric, and
thus matches the same set of strings as defined by 2616+2396.

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Jul 2009 22:11:36 +0200

> In which case I think a proxy is allowed to add it back in.

Which is exactly what the paragraph you quoted earlier says. If read in
context with the paragraph above which it refers to it becomes clearer:

The conditions you have to fulfill here are as follows (from p1 5.1.2
request-target), skipping comments and example text:

        The most common form of request-target is that used to identify
        a resource on an origin server or gateway. In this case the
        absolute path of the URI MUST be transmitted (see Section 2.1.1,
        path-absolute) as the request-target, and the network location
        of the URI (authority) MUST be transmitted in a Host header
        field.
        
        Note that the absolute path cannot be empty; if none is present
        in the original URI, it MUST be given as "/" (the server root).
        
        If a proxy receives a request without any path in the
        request-target and the method specified is capable of supporting
        the asterisk form of request-target, then the last proxy on the
        request chain MUST forward the request with "*" as the final
        request-target.
        
        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 "/".

Which highlights a minor editorial issue.. the 'MUST be given as "/"'
perhaps should mention "*" as well to avoid conflict with that MUST
requirement. But there isn't much room for doubt if one actually reads
the whole 5.1.2 section..

Note for those who look at the text found in 2616: The "*" MUST
requirement was in 2068, but somehow got lost in 2616, and is now
resurrected in HTTPbis.

Regards
Henrik