W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003


From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Mon, 24 Nov 2003 15:58:59 -0700 (MST)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.53.0311241538170.46155@measurement-factory.com>

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.

Received on Monday, 24 November 2003 17:59:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:24 UTC