OPTIONS * and proxies

[mnot@…]

The following text was in RFC2068, but dropped from RFC2616;

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

This makes it impossible for a proxy to forward an OPTIONS * request, because "*" is not a valid URI (as opposed to "/*"). One solution would be to reinstate the text, but that would require proxies to understand a method-specific case.

[julian.reschke@…]

This really is in P1.

[julian.reschke@…]

From [403]:

restore RFC 2068 text describing how to proxy OPTIONS * (addresses #83)

[julian.reschke@…]

See ​http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0156.html:

Didn't we reinstate the * rule regarding this? Yes we did.

​http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging- latest.html#rfc.section.4.1.2

and a trivial editorial correction needed there:

old:

except as noted above to replace a null path-absolute with "/".

new:

except as noted above to replace a null path-absolute with "/" or "*"."

[julian.reschke@…]

From [821]:

note that proxies can rewrite empty paths to "*" as well (for OPTIONS *) (related to #83)