OPTIONS *

[mnot@…]

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:

• Apache (for instance, additional method names supported by mod_dav aren't listed) and
• generic Java servlet engines (servlet API does not support delegation of requests against "*" to all installed web applications)

[fielding@…]

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.

[julian.reschke@…]

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.