Lisa Dusseault wrote:
> I'd like to see wider input before diverging from what I see as pretty
> standard practice. Is OPTIONS * dead? Is it useful? Both?
It can't be both. As far as I'm concerned it doesn't work (or at least
it doesn't do what you're asking it for).
> I had always seen OPTIONS * to be very useful. At Xythos, we went to a
> deal of effort to make it work even though the Xythos WFS was a java
> servlet-based technology. Xythos WFS worked with clients that expected
> to find useful information in OPTIONS *, including the Xythos WFC
> (before that, Teamstream behaved the same way, I think). The clients
> looked for features advertised in OPTIONS *, so that the client would
> know whether it would be worthwhile querying individual resources for
> further detail on supported features.
I've been working on both WebDAV server and client informations for over
three years now, and I haven't *seen* any client making that request
(and if some clients *did* make that request, they obviously proceeded
without that information ok; otherwise I'd definitively had gotten
customer complaints).
> Some clients, like Microsoft clients, use OPTIONS '/', which can be just
> as hard or harder for the server to support than OPTIONS *. And if the
That's a known bug in older Microsoft clients; it has been fixed for a
long time.
> server doesn't advertise a major feature in OPTIONS * or OPTIONS /, then
> the client doesn't bother looking for the feature on individual URLs --
> it's probably too prohibitive to do that roundtrip on every resource
> visited. I think that a server implemented today that didn't put
> features in OPTIONS * or OPTIONS / would find that some clients failed
> to enable features that would otherwise be enabled. This may be most
> true for WebDAV features like locking.
I'm not aware of any such client except for the Microsoft Windows XP
WebDAV Mini-Redirector (which does OPTIONS /), and in that case
Microsoft has indeed acknowledged that this is a client bug:
<http://support.microsoft.com/?kbid=831805>.
Besides, can we please distinguish between "*" and "/"? They are *very*
different? "OPTIONS /" returns communication options for the root URL,
this is well-defined and will work with any compliant server.
> I'm now in the position of developing a WebDAV client from the ground
> up, rather than a server, as I've done before. I assure you that the
> client would rather have some indication (in OPTIONS * or OPTIONS / or
> elsewhere) that a feature might be supported somewhere in the
> repository. This is so that a GUI can show a button as enabled or
> disabled right away, as the client navigates through a bunch of
> resources. For example, the "lock" button should be visible on the
> toolbar when the user is navigating a repository that might support
> locking somewhere -- but the "lock" button should be at least greyed
> out, if not absent, when the user is navigating a repository that
> doesn't support locking at all.
Support for locking will vary across resources; this particular piece of
information can better be obtained by using the "DAV:" header on the
collection you're looking at
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_DAV>).
BTW: so what will you do when the server does *not* support "OPTIONS *"?
> Developers hate uncertainty, but users are generally better at dealing
> with it than we think they are. It's a principle of good user interface
> to show affordances for things that might be possible. It's OK if the
> affordance doesn't work once in a while -- it's better than the user not
> to be allowed, or not to know, that they can even do the function in the
> first place. That's why I think it's good for OPTIONS * to show that a
> feature like locking is available somewhere in the repository, even if
> it's not available everywhere.
So exactly what do you do when the Allow header upon "OPTIONS *" doesn't
contain LOCK? Enable or disable that button?
> Perhaps the solution is to fix the tools. Java Servlets could easily
> have been designed to make OPTIONS * aggregate information from a number
> of servlets. Reverse proxies could send OPTIONS * requests to the
> different servers and bundle the answers together, if the set is finite
> and known. Or we could provide some way of responding to OPTIONS * with
> a specific advertised caveat that "this response does not have the list
> of features available in the repository(ies) that can be addressed at
> this server".
>
> In any case, this issue affects PATCH no more than it affects any other
> HTTP extension.
That's correct; however other specifications are simply silent about
that topic, while the current text for PATCH makes the impression that
this is a feature that's going to work in some reliable fashion. This is
simply incorrect.
Regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760