- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Mon, 19 Apr 1999 19:36:39 -0700
- To: w3c-dist-auth@w3.org
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 that > 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