- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Tue, 20 Apr 1999 00:17:34 -0400
- To: ejw@ics.uci.edu, w3c-dist-auth@w3.org
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