- 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
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.
Received on Monday, 24 November 2003 17:59:01 UTC