W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1999

RE: Some problems with the WebDAV protocol

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 19 Apr 1999 19:36:39 -0700
To: w3c-dist-auth@w3.org
Message-ID: <000a01be8ad6$9df70a80$d115c380@ics.uci.edu>
Henrik Nielsen wrote:
> IMO, it seems out of bounce to impose a MUST requirement in order to
> prevent a "user error" - especially because the "error" doesn't break
> anything in the protocol or leads to interoperability problems.
> This is why it is stated as it is in HTTP/1.1 - it is left to the
> server to decide whether it wants to create the new location or not.
> As Yoram points out, some servers already do that and others don't.

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?

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

> >For example:
> >
> >http://example.com/foo/fuzz/bar.html
> >
> >This URL would be free floating if you removed the "bar.html"
> path segment
> >to create:
> >
> >http://example.com/foo/fuzz/
> >
> >AND if this URL is not mapped to a resource.
> 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.

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.

> In any case, 409 is not the appropriate status code to use - the two URIs
> you have in your example really aren't the same and the problem is not
> there are any conflicts.

We chose 409 because when the conditional in the If header evaluates to
false, it returns a 412 (the only other status code which makes sense here).
Since If would frequently be passed on a PUT in WebDAV (to pass the lock
token), we wanted to make sure the two error conditions would be
distinguishable by a client.

Given this objective, we could have either (a) used 409 (b) used another,
less appropriate status code, or (c) created a new status code.  Since the
status code namespace is rapidly filling, we didn't want to make a new one
if we could help it.   Use of other status codes:

400, 401, 402, 404, 405, 406, 407, 408, 410, 411, 413, 414, 415: Not
appropriate due to definition of the status code.

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

- Jim
Received on Monday, 19 April 1999 22:38:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:19 UTC