Re: HTTP/1.1 & Proxies

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

Yikes, yet another contradiction.  Note that the paragraph describing
"*" refers to server, not origin server, precisely because we want to be
able to send it to a proxy.  A proxy can't forward an

    OPTIONS * HTTP/1.1

request because there is no destination URL given that would indicate
where to forward it.  That is why we know it won't be forwarded by
an HTTP/1.0 (or otherwise broken) proxy.

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

That is not a problem; that is a benefit.  We want that information anyway.

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

PEP would be just as broken in this case.  A broken proxy would either
refuse the request on the basis of a PEP-* method (the same effect as
using OPTIONS) or blindly forward the request, in which case the
required behavior of PEP has failed.

BTW, there is no reason why the OPTIONS request and/or response cannot
carry PEP header fields.

.....Roy

Received on Wednesday, 2 July 1997 13:02:53 UTC