W3C home > Mailing lists > Public > ietf-http-ext@w3.org > January to March 1998

OPTIONS issues from Koen

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

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 
Received on Monday, 2 March 1998 02:54:42 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:07 UTC