RE: Some problems with the WebDAV protocol

> The notion that interoperability problems can be solved if people just
> upgrade their application is often used as incentive for buying commercial
> software but it doesn't apply here. Especially because the
> problem that DAV solves is not a correctness problem but a usability
> issue (not by mistake to create a resource with a unintended URI).

You're putting words in my mouth. I never suggested that people need to
upgrade their application. In fact, existing PUT capable HTTP/1.1 authoring
tools will work against a DAV server just fine. I also provided more
rationale for the decision than just the user interface concerns you have
latched onto.

But, while we're at it, here's a third rationale:

* Prevention of side-effects by PUT

To foster better separation of concerns in the protocol, once the MKCOL
method was introduced, we did not want to have two methods capable of
creating collections.

>
> According to the current set who claim to implement HTTP/1.1 and have
> filled out the feature form:
>
>	http://www.w3.org/Protocols/HTTP/Forum/Reports/rollup.txt
>
> more than half of the clients and half of the servers support PUT. Note
> that authoring in the strict sense of editing web pages is only one
> application of PUT - it can just as well be used for "copy" type
operations.

OK, now you're 1/4 of the way to a compelling argument.

What I need to see beyond this is evidence that actual use of PUT in these
downlevel clients depends on the collection-creating side-effect
capabilities of PUT.  Since this ability to create collections as a
side-effect is not guaranteed by the protocol, the coding of these clients
cannot depend on this capability.  But, though I am skeptical, there might
be compellingly large numbers of people using HTTP/1.1 PUT authoring with
specific client/server pairs who do depend on this capability.  I am willing
to be convinced, but I need to see some numbers.

As a counter-example, I know that at UCI, one of the ways that instructors
and teaching assistants update the web pages for their classes is by using
HTTP PUT, typically in conjunction with the authoring capabilities of
Navigator.  However, to the best of my knowledge, this use of PUT does not
depend on the side-effect capabilities of PUT to create collections.

> The fact that the example uses access authentication is not important -
> what is important is that it is fairly easy to create an example where a
> WedDAV client can't determine whether a server fulfilled the MUST or not -
> the term "exist" is relative to who is asking with the "incoming" FTP
> folder being the example.

Following this path gets quickly into arguments about whether namespace
consistency is or is not a good thing.  We've argued this before without
convincing each other -- shall we go another couple rounds?

> as well as 417-499. As the constraint you have imposed is not in HTTP/1.1
> it is not surprising that none of the existing HTTP/1.1 status codes match
> very well. A new code would have been appropriate.

So, why wasn't this brought up during one of the *three* working group last
call for comments periods on RFC 2518?

- Jim

Received on Tuesday, 20 April 1999 13:07:27 UTC