Re: HTTP/1.1 & Proxies

At 02:23 PM 7/1/97 -0700, Roy T. Fielding wrote:
>>One problem using the OPTIONS method is that it has to be forwarded to an
>>origin server.
>
>Nope.  
>
>    OPTIONS * HTTP/1.1
>    Host: blah
>
>is never forwarded.

This doesn't fit with the description in Section 5.1.2:

...
The absoluteURI form is required when the request is being made to a proxy.
The proxy is requested to forward the request or service it from a valid
cache, and return the response. Note that the proxy MAY forward the request
on to another proxy or directly to the server specified by the absoluteURI. 
...

and later in the same section

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

nothing about proxies _not_ forwarding requests. Hence I would expect a 400
(Bad Request) from the proxy and not a 200 (OK).

Section 9.2 also doesn't seem to indicate that a proxy can respond without
forwarding the request. Only that proxies "MUST edit the response to
exclude those options which apply to a proxy's capabilities and which are
known to be unavailable through that proxy."

>Besides, even if you include a full URL to
>test the whole proxy chain, the OPTIONS method is still safe.

It seems that what we are looking for is not particularly the features of
OPTIONS but instead something that forces an error if not supported. That
is, we use the OPTIONS method because it is not part of HTTP/1.0 and hence
is bound to confuse HTTP/1.0 proxies and servers.

The problem, however, is that OPTIONS is part of HTTP/1.1 and hence when
more   and more applications start to understand OPTIONS, we end up with a
situation where clients generate unnecessary requests that are understood
and handled by servers.

Instead, I propose to use something like PEP which has the exact feature of
forcing an error message if either existing or future servers either don't
understand or don't want to handle an extension. This is easy to stop and
does not have to propagate requests beyond the first step.

I am currently writing up a revised version of PEP based on the inputs we
have received from Koen and others. We are also close to have PEP demo
software ready can be used to demonstrate some of the features in PEP. The
draft will be ready by July 14.

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Wednesday, 2 July 1997 08:31:30 UTC