httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39287] New: - Incorrect If-Modified-Since validation (due to synthetic mtime?)
Date Wed, 12 Apr 2006 18:06:04 GMT
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=39287>.
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=39287

           Summary: Incorrect If-Modified-Since validation (due to synthetic
                    mtime?)
           Product: Apache httpd-1.3
           Version: HEAD
          Platform: All
               URL: http://www.mnot.net/cgi-bin/apache-ims.cgi
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: issues.apache.org@mnot.net


Apache 1.3 (and 2.0, as far as I can see) calculates the modified time used to compare the
If-Modified-
Since request header with and determine validation like this (in http_protocol.c ap_meets_conditions);

    mtime = (r->mtime != 0) ? r->mtime : time(NULL);

Later, this time is used to figure out if a 304 Not Modified is sent;

        if ((ims >= mtime) && (ims <= r->request_time)) {
            return HTTP_NOT_MODIFIED;

The problem is that Apache fakes the mtime to the current time if it can't find r->mtime
(e.g., if it's a 
CGI script). If a client sends an If-Modified-Since header, I believe there's a race condition
whereby an 
IMS containing the current time will get a 304 Not Modified, even though the underlying resource
has 
no concept of mtime (i.e., it doesn't have a Last-Modified).

This can be demonstrated against the following script (at http://www.mnot.net/cgi-bin/apache-
ims.cgi):

#!/usr/local/bin/python
import os
print "Content-Type: text/plain"
print
print os.environ.get("HTTP_IF_MODIFIED_SINCE", "-")

using the following command-line for the client side;

~> URL="http://www.mnot.net/cgi-bin/apache-ims.cgi"; DATE=`curl -Is -X HEAD $URL | grep
^Date | 
cut -d ":" -f 2-`; echo "D-> $DATE"; curl -Is -H "If-Modified-Since: $DATE" $URL
D->  Wed, 12 Apr 2006 17:58:39 GMT
HTTP/1.1 304 Not Modified
Date: Wed, 12 Apr 2006 17:58:39 GMT
Server: Apache/1.3.29

As you can see, Apache incorrectly sends a 304 Not Modified when the If-Modified-Since request

header is set to the current time. For a CGI script that changes on a sub-second basis (e.g.,
one used 
by AJAX), this reduces the granularity of responses to one second, confusing the implementor
(because 
they don't expect a 304 Not Modified to ever be sent).

All of this would be largely a theoretical problem, because such a resource should never see
an If-
Modified-Since request header, having not send a previous Last-Modified response header. However,

Safari/OSX *does* send a If-Modified-Since request header based upon the Date response header
when 
it doesn't find a Last-Modified response (a bug which I'm reporting to them now). 

Safari, of course, should fix themselves, but Apache is also somewhat broken here, as it should
not 
default mtime to the current time (which may cause problems in other scenarios).

Note that while I see this behaviour on the mnot.net server (Apache 1.3.29), I've had trouble
verifying it 
on other systems. I suspect that this is because it's a race condition, and therefore hard
to reproduce; 
that said, it could be something on that particular server instance (it's a shared host, so
I dont' have 
access to the source they've used). 

However, if I'm correct about the underlying reason, the code hasn't changed from then until
HEAD, and 
is substantially the same in Apache 2.2.0.

-- 
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message