Summary: | One Failed Request Can Possibly Overwrite Another Active Request's PUT | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Steve <lardcanoe> |
Component: | mod_dav | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | julian.reschke |
Priority: | P2 | Keywords: | FixedInTrunk |
Version: | 2.0.55 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other |
Description
Steve
2006-01-06 00:25:02 UTC
I do agree that the delete-on-failed-PUT behaviour is a bug, at least in the case of modifying an existing file. Perhaps it is useful for the case where the resource did not exist before. To completely avoid concurrency problems like this mod_dav_fs would also have to lock the file. That should be relatively simple to do but needs further analysis. w.r.t. doing a the stat()-after-PUT; that would not eliminate the race; another process could still modify the file after the stat() and the returned status code would be "wrong" again Since the fix for PR 39815 in trunk, a PUT request without range header goes to a temporary file first. This means that a failed PUT will only unlink its temporary file and not the real target file. I belive this is a sufficient fix for this issue. fixed in 2.4.1 |