DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42896>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42896 ------- Additional Comments From [EMAIL PROTECTED] 2007-07-17 07:47 ------- (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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
