- From: Josh Cohen <joshco@microsoft.com>
- Date: Sun, 1 Mar 1998 23:54:39 -0800
- 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 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
Received on Monday, 2 March 1998 02:54:42 UTC