Subject: Re: Proxying OPTIONS *

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 01 Oct 2007 22:56:50 +0200

On sön, 2007-09-30 at 16:54 -0700, Roy T. Fielding wrote:
> On Sep 30, 2007, at 4:05 PM, Nick Kew wrote:
> 
> > RFC2616 is clear that:
> >   1.  OPTIONS * is allowed.
> >   2.  OPTIONS can be proxied.
> >
> > However, it's not clear that OPTIONS * can be proxied,
> > given that there's no natural URL representation of it (* != /*).
> 
> An absolute http request-URI with no path.

Hmm.. this was lost in RFC2616 it seems. This was mentioned in 2068
5.1.2 Request-URI, but vanished in 2616 without a trace..

Anyone remember why?

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Oct 2007 23:49:25 +0200

> 5.1.2 Request-URI, but vanished in 2616 without a trace..

The change doesn't appear in "19.6.3 Changes from RFC 2068" 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.19.6.3>) 
which may indicate that it wasn't reviewed properly.

For the record, the missing text is

" If a proxy receives a request without any path in the Request-URI and
    the method specified is capable of supporting the asterisk form of
    request, then the last proxy on the request chain MUST forward the
    request with "*" as the final Request-URI. For example, the request

           OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

    would be forwarded by the proxy as

           OPTIONS * HTTP/1.1
           Host: www.ics.uci.edu:8001

    after connecting to port 8001 of host "www.ics.uci.edu"." -- 
<http://tools.ietf.org/html/rfc2068#section-5.1.2>

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 04 Oct 2007 01:10:11 +0200

> <http://tools.ietf.org/html/rfc2068#section-5.1.2>

There is one slight problem with the above and it's " and the method
specified is capable of supporting the asterisk form of request". This
requires the proxy to know about each such method, and with HTTP being
extensible it's not fully possible. In RFC2616 only OPTIONS meets this
criteria.

Is there a possibility for other methods than OPTIONS which may make
sense on a global resource-less context? I think not. If this is
complemented with a restriction that the special request-URI "*" may
only be used in OPTIONS requests then it's fine. Interoperability of
extension methods using "*" will be tricky at best..

Please put this into the issues list, starting with julians response.
http://www.w3.org/mid/[email-masked]

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Oct 2007 16:43:08 +1000

Now i83.

<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i83>

--
Mark Nottingham     http://www.mnot.net/