Bug 16521 - caches MUST treat invalid Expires values as in the past
Summary: caches MUST treat invalid Expires values as in the past
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cache (show other bugs)
Version: 2.0-HEAD
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://coad.measurement-factory.com/c...
Keywords: PatchAvailable, RFC
Depends on:
Blocks: 50195
  Show dependency tree
Reported: 2003-01-29 00:15 UTC by Co-Advisor
Modified: 2011-02-12 17:07 UTC (History)
0 users

"Expires: 0" case trace (16.53 KB, text/html)
2003-01-29 00:16 UTC, Co-Advisor
"Expires: yesterday" case trace (16.62 KB, text/html)
2003-01-29 00:25 UTC, Co-Advisor
Patch submitted by Kris Verbeeck <kris.verbeeck@chello.be>. See next comment for more info. (664 bytes, patch)
2003-07-03 15:14 UTC, Paul J. Reder
Details | Diff
test case trace (extended RFC850 format) (16.86 KB, text/html)
2003-07-07 18:36 UTC, Co-Advisor
Fix for handling the date ending with extra junk characters. (1.03 KB, patch)
2003-07-09 06:33 UTC, Sushma Rai
Details | Diff
a safer version of the patch in attachment 7186? (1.87 KB, patch)
2003-07-21 19:53 UTC, Co-Advisor
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Co-Advisor 2003-01-29 00:15:37 UTC
Looks like a possible RFC 2616 MUST violation.
Various malformed Expires header values (including the
"0" value explicitly mentioned by RFC 2616) are not
treated as "in the past".
See attached trace(s) for details and ways to reproduce
the violation mentioned above.

Test case IDs in the trace link to human-oriented test case
description and RFC quotes, if available.
Comment 1 Co-Advisor 2003-01-29 00:16:27 UTC
Created attachment 4610 [details]
"Expires: 0" case trace
Comment 2 Co-Advisor 2003-01-29 00:25:16 UTC
Created attachment 4612 [details]
"Expires: yesterday" case trace
Comment 3 Paul J. Reder 2003-07-03 15:14:36 UTC
Created attachment 7085 [details]
Patch submitted by Kris Verbeeck <kris.verbeeck@chello.be>. See next comment for more info.
Comment 4 Paul J. Reder 2003-07-03 15:17:17 UTC
(Comments by Kris Verbeeck. Easier to find them if they are in the PR.  - Paul
J. Reder)

PR 16521 states that mod_cache caches and returns responses that have an invalid
Expires header (value is 0 or yesterday).  The attached patch resolves this issue.

Some explanation:
- when apr_date_parse_http returns APR_DATE_BAD, the local variable containing
the expires header was reset to NULL;
- the check a bit lower in the code:

    if (exps != NULL && exp == APR_DATE_BAD) {

would always fail because when exp equals APR_DATE_BAD, exps was always NULL.
Comment 5 Co-Advisor 2003-07-07 18:36:36 UTC
Created attachment 7125 [details]
test case trace (extended RFC850 format)
Comment 6 Co-Advisor 2003-07-07 18:41:20 UTC
Getting closer! With the proposed patch, "0" and "yesterday"
cases pass as do other 8 cases in this "bad Expires" clause.

However, one test case still fails. The failed test case deals
with dates in RFC 850 format followed by junk. Perhaps Apache
is forgetting to check that no "extra" characters exist after
partsing RFC 850 dates correctly? The trace for the failed case
is attached.

Thank you.
Comment 7 Sushma Rai 2003-07-09 06:33:23 UTC
Created attachment 7186 [details]
Fix for handling the date ending with extra junk characters.
Comment 8 Sushma Rai 2003-07-09 06:36:21 UTC
This patch (attachement ID 7186)is to fix the 
date followed by junk, in all RFC 850, RFC 1123 
and Asctime formats.

Do we need to handle the condition where the 
Date is not represented in GMT or no time 
zone is specified? 
(Example: "Sun, 06 Nov 1994 08:49:37 ")

RFC 2616, 3.3.1 says: 

	All HTTP date/time stamps MUST be represented in GMT,  
	without exception. 

   	HTTP-date is case sensitive and MUST NOT include
   	additional LWS beyond that specifically included as SP in the

   	Note: Recipients of date values are encouraged to be robust 
      	in accepting date values that may have been sent by non-HTTP
      	applications, as is sometimes the case when retrieving or 
      	posting messages via proxies/gateways to SMTP or NNTP.
Comment 9 Co-Advisor 2003-07-21 19:09:55 UTC
IMO, yes, you do. Recall that we are talking
about cache freshness here. A cache is a performance
optimization with serious freshness side-effects.
We should err on the safe side (generate a miss, not
a hit) whenever there are doubts.

The above does not mean that implementation should
reject messages with invalid expiration dates, of 
course. Just treat them as stale.
Comment 10 Co-Advisor 2003-07-21 19:53:07 UTC
Created attachment 7430 [details]
a safer version of the patch in attachment 7186 [details]?
Comment 11 Co-Advisor 2003-07-21 19:59:43 UTC
The patch in attachment 7186 [details] (when used with the original patch
in the attacment 7085) leads to coredumps. I am not an Apache
developer, but it looks like "timstr" may be NULL while it is
used in the if-statement in the attachment 7186 [details].

Attachment 7430 [details] contains a safer combination of the above mentioned
two patches. It does not lead to coredumps and does let Apache pass
all test cases in this test clause. I do not know if it does the
right thing overall though. Please check.
Comment 12 Jeff Trawick 2003-11-21 17:20:21 UTC
I'm going through the bug db to make sure patches are findable.  Please see 
Comment 13 Co-Advisor 2005-06-06 22:02:48 UTC
FYI: this violation seems to be present in httpd-2.0.54
Comment 14 Graham Leggett 2011-02-12 17:07:50 UTC
The fix to the Expires being treated as missing instead of in the past when a bad date arrives is fixed on trunk in r1070128.

As to rejecting the junk characters at the end, some browsers such as Netscape have inserted junk at the end in the past, and it's safer to be lenient in what we accept. The APR people, when asked, said no to being more restrictive than strictly necessary, so this bit is wontfix.