OPTIONS issues from Koen

From: Josh Cohen (joshco@microsoft.com)
Date: Mon, Mar 02 1998


Message-ID: <8B57882C41A0D1118F7100805F9F68B5A789E6@red-msg-45.dns.microsoft.com>
From: Josh Cohen <joshco@microsoft.com>
To: "ietf-http-ext (E-mail)" <ietf-http-ext@w3.org>
Date: Sun, 1 Mar 1998 23:54:39 -0800 
Subject: OPTIONS issues from Koen

Here are some of the other issues koen had
mentioned on OPTIONS;
(koen, if Im missing any important ones or
 somehow misrepresenting what you said, let me know)

1. The server may be compliant with a certain spec or extension, but that
may not be available for every request.

 My previous post suggests a solution to this.
 [ a server should include a non-compliance header to
responses from cgi's or server modules for which it cannot vouch for
compliance. ]
 
2. What if you are both an origin server AND a proxy server?

 There could be some ambiguity in this case, but
I cant think of real examples.  In my mind, as someone
who thinks like a (former) proxy implementer, I think
of using OPTIONS for baseline server functionality which wouldnt be specific
the role of proxy or server operation for a multifunction machine.

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.

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.



---
Josh Cohen <josh@microsoft.com>
Program Manager IE - Networking Protocols