Bug 54962 - Apache will set incorrect Content-Length header and may serve partial files
Summary: Apache will set incorrect Content-Length header and may serve partial files
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-14 05:57 UTC by Richard Fliam
Modified: 2013-05-14 05:57 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Fliam 2013-05-14 05:57:51 UTC
We have several files which are moved (renamed) on top of frequently (about every 2 seconds). 

A rename or move operation is atomic in the kernel, and thus should not cause issues. However, due to the nature of the way Apache serves these files it will periodically serve an incorrect Content-Length header and a truncated file or not enough bits.

Steps to Reproduce:
Take a file, perhaps randomly generated.
Move (mv, or c rename()) a new one of differing size onto it with a relatively high frequency.

Cause:
Apache "stats" a file on receiving a request. It than opens a file descriptor for that file on line 4314 of core.c, and sets the content length header using `ap_set_content_length(r, r->finfo.size)` on 4328. This is the core of the problem, r->finfo.size is from a `stat()` that may not be the same inode.

The better (correct?) behavior is to use `fstat()` on the open file descriptor to set the Content-Length header as well as send size for sendfile etc. As file descriptors refer to an inode in most operating systems this prevents the underlying race on files which are being (atomically) updated.

To be clear this is not the same as having issues reading from a file that is being modified, the file is updated atomically and many other application (such as Python) handle this correctly.