Summary: | Incorrect If-Modified-Since validation (due to synthetic mtime?) | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Mark Nottingham <mnot> |
Component: | Core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | dabuq |
Priority: | P2 | Keywords: | PatchAvailable |
Version: | 2.5-HEAD | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | FreeBSD | ||
URL: | http://www.mnot.net/cgi-bin/apache-ims.cgi | ||
Attachments: | Fix If-Modified-Since "now" with non-mtime-aware resources, add missing APR_DATE_BAD check. |
Description
Mark Nottingham
2006-04-12 19:06:03 UTC
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!" Created attachment 29237 [details]
Fix If-Modified-Since "now" with non-mtime-aware resources, add missing APR_DATE_BAD check.
No response within six years although the fix is easy:
Keep assuming that r->mtime == 0 means "now" but check for mtime == 0 explicitly instead of faking mtime = apr_time_now(). Note that this will break the If-Unmodified-Since check if the requested resource really has an mtime of 1970-01-01T00:00:00 (but how likely is that?).
A thorough fix would be to introduce a "time unset" constant as already stated in a comment by dgaudet.
A quick test shows Mark Nottingham's test case still elicits the bug with httpd trunk (2.5.0-dev) r1470940. I just retested this and the test case still elicits the bug in 2.4.12, 2.4.13-dev (r1665365), and 2.5.0-dev (r1665394), running on OSX 10.9.5. There's been enough code change that Carsten Gaebler's patch no longer applies cleanly, but it looks like the current code still has the same bug/behavior as the old code: if the resource has no last-modified date, it acts as if the last-modified date is apr_time_now(). |