Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

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

Received on Friday, 21 May 2004 17:09:42 UTC