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

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

Received on Friday, 21 May 2004 16:46:22 UTC