If a client sends a PUT message containing a content range field and an error is experienced while receiving the data, dav_method_put function will delete the entire file. For example if a client sends a request such as: PUT /davtest/1gb.txt HTTP/1.1 content-range: bytes 1048576-2097151/* User-Agent: FPDAV client/1.0 Host: mars.tivlab.westford.ibm.com Content-Length: 1048576 Connection: Keep-Alive Authorization: Basic dXNlcjpwYXNzd29yZA== is sent by the client and a network error occurs during the receipt of the message body then the entire file is deleted before the dav_method_put returns. I believe this behavior is wrong and dav_method_put should do one of the following: 1. leave the file the way it is even with the modifications. 2. restore the file to the way it was before the modifications. At the very least dav_method_put should not delete the file if the error happened before any modifications are made to the file. I realize this way of using PUT is may not be clear in any specifications but since Apache is making an attempt I would like to explore the possibility of making it more useful until a better means up updating byte ranges of a resource comes along. I am eager to discuss a short term and to discuss any future directions Apache may take to accomplish this (such as implementing the PATCH method)
See also bug 38148 - I do think this behaviour is undesirable and I can't see any reason why it's necessary, but I might be missing something.
(In reply to comment #1) > See also bug 38148 - I do think this behaviour is undesirable and I can't see > any reason why it's necessary, but I might be missing something. I think people will come down on many different sides of this issue but I think in the end everyone will agree that at least one change is necessary. One reason for this change is: When a client is doing a PUT request without the content-range field they would typically keep the entire contents of the file around until the server indicates success. So in this case a client has the entire contents of the file and can easily provide it to the server again to restart after an error. It does not matter in this case if the server deletes the file after an error. This is not necessarily true for a client using the content-range field. So after the server experiences the error and deletes the file the client may not be able to reproduce the file. The client is asking for a portion of the file to be changed so if an error happens during the transmission of that request the dav_method_put function should restore the file back the way it was (or do nothing which is really all I personally would require). For a PUT that does not contain the content-range this would mean deleting the file. But for a PUT that does contain the content- range deleting the file does much more than undoes what the request was attempting to do. Also, I think the differentiating factor between this and the bug 38148 is the presence of the content-range field. They can be addressed independentally.
I confirm problem with Apache 2.0.55 on Windows Server 2003... Content-Range not run with PUT command...
Created attachment 21687 [details] This is a patch that we are using to work around this problem Last year we developed a work-around to this problem in the form of the attached patch. I would, of course, would like to get it into apache (or even just WebSphere) but I have not made much forward progress on that.
Any news on this? When using Mozilla Sunbird with a ICS file stored in an Apache WebDAV folder this happens very frequently (see also http://getsatisfaction.com/foxmarks/topics/using_webdav_bookmarks_json_gets_deleted_by_the_foxmarks_client#reply_720003 ) I'm currently using Apache 2.2.10 on Gentoo Linux.
fixed in r834062
fixed in 2.4.1