RE: Some problems with the WebDAV protocol

At 19:36 19/04/1999 -0700, Jim Whitehead wrote:
>In *my* opinion, the PUT and DELETE methods never should have been added to
>HTTP without also adding locking support. I consider it a signficant bug
>that a user-agent can issue a PUT (without If-*-Match headers) and overwrite
>someone else's work. Therefore, as an author of the HTTP specification,
>could you please take an action item to have PUT removed from RFC 2068 and
>successors since it is so dangerous?

Nope, it works just fine - many applications do not need anymore.
Furthermore, a server is always welcome to deny accepting a PUT operation
without a precondition. Always start with the simple stuff first and then
layer more complex things on top. 

Only real problem was that client couldn't force acceptance of new
attributes in the PUT request like for example support for PUT with byte
ranges but HTTP extensions makes that much simpler through mandatory
extension declarations.

>> Removing the MUST requirement would also eliminate any problem with
>> HTTP/1.1 clients - removing their capability of creating
>> resources is in my mind not a good transition strategy.
>
>A transition strategy for what? If someone can provide hard data (instead of
>opinion and personal conjecture) that this is a serious interoperability
>problem, I could be convinced that some action needs to be taken. But, given
>that there is, to the best of my knowledge, *very* limited HTTP/1.1
>authoring in practise, and given that these clients have to have been
>designed to work against servers which do not support the creation of
>intermediate collections (the DAV semantics), and since there are
>workarounds to address the need to create intermediate collections, I am
>finding it hard to believe that there is, indeed, a problem here.

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

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.

>> But what if "http://example.com/foo/fuzz/" exists but isn't accessible to
>> me because I don't have the right permissions. In that case, I may get a
>> 403 (Forbidden) when accessing "http://example.com/foo/fuzz/" but still be
>> able to create the document "http://example.com/foo/fuzz/bar.html".
>
>a) Access control policy is not addressed by the WebDAV specification.

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.

>b) If this scenario is a problem for DAV, it seems to me it's also a problem
>for downlevel HTTP/1.1 clients too, since what you're alluding to is a
>general problem having to do with the implications a restriction on one end
>of a containment relationship has on the other end.

No, as HTTP/1.1 doesn't have the requirement that "all ancestors MUST
already exist" then it can create the resource
"http://example.com/foo/fuzz/bar.html" just fine without caring about
whether /foo and /foo/fuzz exist or not.

>This leaves:
>
>403: While this may seem appealing, and perhaps could have been made to
>work, it didn't seem right since if a user agent creates the intermediate
>collection, they could and should resubmit the PUT request.  It didn't seem
>to us that this was a case where, "the server does not want to reveal
>exactly why the request has been refused"
>
>409 & 412: see above

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.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Tuesday, 20 April 1999 00:17:50 UTC