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