Re: OPTIONS issues from Koen

> Here are some of the other issues koen had
> mentioned on OPTIONS;
> 
> 1. The server may be compliant with a certain spec or extension, but that
> may not be available for every request.

  The server should answer for itself when the request was for *, and
should pass the request through to an active component if the request was
specific to that component (/cgi-bin/foo); the fact that most of those
today won't do the right thing is something we can't do anything about
except structure a correct response to OPTIONS such that an existing CGI
wouldn't send it so you can tell you are talking to something that doesn't
understand the method.

> 2. What if you are both an origin server AND a proxy server?

  It seems to me that one of the things you should get back when you send
OPTIONS * to a server is exactly whether or not it will act as a proxy, an
origin server, or both.  Sounds like something we need to add.

> 3. should chained proxies declare a non-compliance header or remove a
> compliance header when passing a response back which contains a compliance
> header from another server/proxy which this proxy doesnt understand or
> support.

  They should never remove or alter any part of the response; they should
always add thier own response to it so that the requestor can see the
capabilities of the chain as a whole and determine what part of the chain
is the problem.

> 4. How does unknown method tunneling affect this
>  While the '*' URI would not typically be forwarded on,
>  since there is no indication of who to contact as an
>  origin server, an OPTIONS with a URI with a host might
>  get unknowingly forwarded.

>  A possible workaround might be that if the host: header points to a the
> proxy itself, then the proxy must not forward the OPTIONS request onward.

  I don't understand the question on this last one.

Received on Monday, 2 March 1998 09:54:22 UTC