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=43386>. 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=43386 ------- Additional Comments From [EMAIL PROTECTED] 2007-09-19 00:35 ------- AFAICS rahuls patch is all that is needed. It updates r->finfo that Content- Length, Last-Modified, and ETag headers will be consistent with the content. Even if the file is replaced concurrently, the request will either return the old file or the new file. For me this atomicity is a vital property which for the last ten years I took for granted to be implemented in httpd. Sure, if the file is truncated, then all bets are off. But if the content provider goes to the trouble to use an atomic replace, then httpd should reflect that to the http client. I am astonished that this seems to be a wellknown long-term bug rather than a regression. -- 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]
