Subject: Re: OPTIONS *

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 09:28:27 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 17:20:35 +0100

Alex Rousskov wrote:
> On Tue, 25 Nov 2003, Julian Reschke wrote:
> 
> 
>>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).
>>
> In my experience, you need to convince one of the original authors or
> anybody Scott Lawrence trusts that a certain change is warranted. If
> you succeed, the change will be posted to
> http://purl.org/NET/http-errata with a link to the discussion on the
> list.
> 
> The change does not have to be an "errata" or "issue" with the
> protocol itself.
> 
> Your best bet is probably to post a specific wording to this list and
> wait for a reaction.

OK, that sounds reasonable. Maybe we can come up with a good replacement 
text.

Julian