Re: OPTIONS *

On Mon, 24 Nov 2003, Julian Reschke wrote:

> 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?

Support for OPTIONS is optional so client should not rely on that
mechanism exclusively. That is, they should expect "405 Method Not
Allowed" or "501 Not Implemented" response, among other things.

Even if OPTIONS method is supported, client cannot expect a list of
supported optional method names in response to OPTIONS * (in general)
because supported optional methods may depend on the request URI. Here
is a quote from RFC 2616, it may also clarify why Java API does not
propagate * requests:

   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).
   ...
   A 200 response SHOULD include any header fields that indicate
   optional features implemented by the server and applicable to that
   resource

HTH,

Alex.

P.S. The "can be used to test a proxy for HTTP/1.1 compliance" phrase
     above probably meant to say "can be used to detect HTTP version
     of a proxy" since one cannot really test for compliance using an
     optional method.

Received on Monday, 24 November 2003 16:33:27 UTC