Re: OPTIONS *

Alex Rousskov wrote:

>>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 *.

That would be my interpretation as well, but I think the wording of 
RFC2616 is really too vague here.

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

Yes.

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

Well, that's what got us here (WebDAV using it for that). However the 
issue here is that the "OPTIONS *" request in reality get's never passed 
to the various 'modules' inside a server that would need to be able to 
respond it (for instance neither Apache/mod_dav nor Tomcat/Webdav 
servlet set the special "DAV:" response header defined for OPTIONS in 
RFC2518).

Any chance to get that onto the RFC2616 issues list?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 25 November 2003 03:31:02 UTC