Re: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)

Lisa Dusseault wrote:

> I'm not so sure about clients assuming "any resource under /".  Do
> you have actual cases there?  For example, even though OPTIONS *
> would return "LOCK, UNLOCK" in the Allow header for a WebDAV
> Level 2 server, WebDAV clients don't necessarily assume that all
> collections really support LOCK.  They can't, because for example
> IIS 5.0 collections don't.  Other situations might arise when the
> principal-URL space doesn't support LOCK even if the regular
> resource space does.  So I think it's already well understood, that
> OPTIONS * means only that the server may in some sub-namespace
> support a feature.
>  
> I didn't mean to denigrate anybody making any points, valid or otherwise.
> Perhaps I should be more clear: if this is a HTTP problem, it needs to be
> brought up in the context of HTTP design (e.g. 
> http://ftp.ics.uci.edu/pub/ietf/http/).
> I haven't heard HTTP implementors (and there are many, many) outside
> of the WebDAV WG complain about OPTIONS *.

That's because

- RFC2518 doesn't require it and
- RFC2518bis has added it without any announcement whatsoever.

How would an HTTP implementor outside the WebDAV working group even 
*know* about that proposed change?

> Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
> to define their behavior in OPTIONS * as well as OPTIONS /specific/uri.

Fine. So please define that WebDAV doesn't put any additional semantics 
on OPTIONS *.

> How could we not define this, when clients use OPTIONS * and servers
> support it?

Only some servers support it (in the way you are trying to mandate it). 
And so far, I haven't seen a client using it for anything WebDAV related 
(for the simple reason that it won't work with all servers).

Julian

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

Received on Monday, 24 November 2003 15:14:21 UTC