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

From: Lisa Dusseault <[email-masked]>
Date: Fri, 21 May 2004 13:45:49 -0700

I'd like to see wider input before diverging from what I see as pretty 
standard practice.  Is OPTIONS * dead?  Is it useful?  Both?

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.

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

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.

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.

Lisa

On May 21, 2004, at 1:04 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> ...
>>> It also cannot be implemented in general over reverse-proxies which
>>> forward requests to different servers depending on the URL.
>>>
>> OPTIONS * is a difficult problem; I don't really have a solution to 
>> it, nor do I know of any consensus on "the right thing" to do about 
>> it.  The requirement is only a SHOULD, since obviously some 
>> implementations can't do this.
>
> I think it's understood that under many cirumstances, "OPTIONS *" will 
> simply not work. Making it a "SHOULD" requirement suggests to clients 
> that they reasonably can expect it to work most of the time; however 
> the *opposite* is true.
>
> Clients can not rely on "OPTIONS *" working as described, and it's 
> also not clear what the value of this feature is. The client can't 
> rely on PATCH being available on every resource, nor can it rely on 
> specific delta formats being supported on all resources.
>
> As such, it should be a "MAY", or even better, the description should 
> be removed altogether.
>
> If you disagree, I'd be interested to hear about a use case where the 
> response from "OPTIONS *" will indeed help the client in any way.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 May 2004 23:08:58 +0200

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

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

> 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 *"?

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

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

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