Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/32
Origin: http://lists.w3.org/Archives/Public/ietf-http-wg/2003OctDec/0048.html
Component: p2-semantics
I'd like to see a clarification about what clients can expect upon OPTIONS *. In particular, can they expect to find out about *any* method name supported on that server? I'm asking because this doesn't seem to be the case for at least two major server bases, being:
The answer is "no" to both expectations. This is very clear already:
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
I don't see any point in listing all the possible things that can't be determined at the server-level; it is implementation-dependent.
Replying to fielding@gbiv.com:
The answer is "no" to both expectations. This is very clear already: If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). I don't see any point in listing all the possible things that can't be determined at the server-level; it is implementation-dependent.
I have to disagree. This question comes up again and again, so it seems the specification is not sufficiently clear.