You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2006/04/12 20:06:04 UTC

DO NOT REPLY [Bug 39287] New: - Incorrect If-Modified-Since validation (due to synthetic mtime?)

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


DO NOT REPLY [Bug 39287] - Incorrect If-Modified-Since validation (due to synthetic mtime?)

Posted by bu...@apache.org.
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





------- Additional Comments From issues.apache.org@mnot.net  2006-04-12 19:12 -------
BTW, there's nothing special about that script; I used the one I'm showing Apple's problem with, but it 
could easily be as simple as 

print "Content-Type: text/plain"
print 
print "hi!"

-- 
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