Re: OPTIONS *

On Mon, 24 Nov 2003, Julian Reschke wrote:

> >    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
>
> I think it would be nice if the spec would clarify what "supported
> in general" means... Specifically for the "Allow" header: does it
> mean
>
> - the methods listed in the Allow header are supported by all resources?
> - methods not listed in the Allow header aren't supported by any resource?
> - something else...?

While "supported by all resources" sounds logical, I suspect the true
intent was to use "*" for things that are not resource-dependent at
all (e.g., server ability to server N concurrent clients or switch to
non-TCP transport). In other words, there should not be any Allow
header returned for OPTIONS *.

I doubt it is possible to formally define what * is referring to
because HTTP does not have a definition of a "server" that is suitable
for this context. Such a definition would be outside of the
communication protocol scope. Essentially, the definition of "*" or
"server" in this context is implementation/environment dependent.

> To me it seems that "OPTIONS *" is effectively useless

It is potentially useful for announcing support for custom server
features _not_ documented in RFC 2616. The documentation for such a
feature would define exactly what to include in or expect from an
"OPTIONS *" response. I bet somebody out there is using it for such
custom purposes.

Alex.