Bug 47693 - GET request has race condition w.r.t. replacement of file being served
Summary: GET request has race condition w.r.t. replacement of file being served
Status: RESOLVED DUPLICATE of bug 54962
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-13 05:23 UTC by alex
Modified: 2020-10-22 08:37 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description alex 2009-08-13 05:23:12 UTC
When a GET request is received by Apache, it first opens the file to determine the length, then closes it, then reopens it to serve the file.

An interesting use case is to replace a file (using an atomic rename) and have Apache give consistent results: always return either the old file or the new file.

However, the current implementation will give inconsistent results when the length of the file changes between the first and second time Apache opens the files.

If the new file is longer, Apache returns the content of the new file truncated to the length of the first file. If the new file is shorter, Apache returns an error response.
Comment 1 Dan Poirier 2009-08-14 04:34:41 UTC
That's all true, but are there are any feasible ways to fix the behavior?  For that matter, what is the right behavior if a file changes in the middle of a request?

The server could ensure consistency by making a complete copy of every file before beginning to serve it, but that's not reasonable for any significant load.  There might be some operating systems where the server could get an exclusive lock on the file before beginning to serve it, but not on most OSes.

Practically speaking, the solution is not to change files under a running server.  Or serve the content from a database or other source with true atomic changes.
Comment 2 alex 2009-09-29 01:38:29 UTC
Perhaps it won't be feasible in terms of internal state management inside the server, but the solution would be to use the following sequence:

open the file, get it's length, read the file, close the file

instead of:

open the file, get it's length, close the file, open the file, read the file, close the file.

Note that the interference with file that I'm talking about is not an arbitrary modification to the file, but only the case where the file is replaced by another file. This is a typical filesystem operation for doing a "clean" / "atomic" modification to a file: write a new copy of the file content to a temporary file, then replace the target file by the temporary file.

Reopening to get feedback on the feasibility of the proposed solution...
Comment 3 Joe Orton 2020-10-22 08:37:27 UTC

*** This bug has been marked as a duplicate of bug 54962 ***