323708 - Recalculation of ComputeFreshnessLife wrong after performing If-Modified-Since / If-None-Match request

Status: RESOLVED FIXED

(Core :: Networking: Cache, defect)

Description

[Kristian Kræmmer Nielsen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When an If-Modified-Since request returns, only the "Date"-header is parsed and not the "Last-Modified" header:
...
0[2c4898]:   If-Modified-Since: Tue, 17 Jan 2006 02:11:55 GMT
...
0[2c4898]: new response header [Date: Tue, 17 Jan 2006 01:26:26 GMT]
0[2c4898]: ignoring response header [Content-Type: image/gif]
0[2c4898]: ignoring response header [Last-Modified: Fri, 29 Apr 2005 07:59:12 GMT]
...
This results in ComputeFreshnessLife using the cached Last-Modified header for calculations agenst a cached or wrong Date-header. Eventuelly the browser will hit different web-servers or caches and the Date and Last-Modified stamps are not compatible basing the heuristic calculation on wrong dates resulting in an overflow in ComputeFreshnessLife:
...
0[2c4898]: using last-modified to determine freshness-lifetime
0[2c4898]: last-modified = 1137463915, date = 1137463885
0[2c4898]: freshnessLifetime = 429496726, currentAge = 396
...


Reproducible: Always

Steps to Reproduce:
1. Empty the cache
2. Request a page with a Last-Modified header from a cache-server
3. Change the Last-Modified to be in the past but still newer than the cached version (in pratical this happens if you hit another cache-server that actually has an older version of the file)
4. Hit the page again

Actual Results:  
From about:cache:

           Key: http://inc.tv2.dk/js/contentbox2.js
     Data size: 1825 bytes
   Fetch count: 9
 Last modified: 2006-01-17 03:16:48
       Expires: 2019-08-28 04:48:58

Expected Results:  
It should base calculation using Date and Last-Modified from the same HTTP-response header.
In the matter of deciting which request, the RFC2616 says to:
"If a cache has two fresh responses for the same representation with
different validators, it MUST use the one with the more recent Date
header. This situation might arise because the cache is pooling
responses from other caches, or because a client has asked for a
reload or a revalidation of an apparently fresh cache entry."

Comment 1

[Kristian Kræmmer Nielsen]

Attachment: Resolving the substraction underflow issue

This patch will resolve the substraction underflow issue in nsHttpResponseHead::ComputeFreshnessLife

This will solve the problem with FireFox caching bits of sites indefinitely but will not solve the initial problem with the heuristic calculation using the Date and Last-Modified header from different requests.

Comment 2

[Darin Fisher]

Comment on attachment 208704 [details] [diff] [review]
Resolving the substraction underflow issue

Thanks for the patch.

Comment 3

[Darin Fisher]

Hmm... it is also the case that the Last-modified header could change if the browser is validating the ETag via If-none-match.  Yeah, the code in nsHttpResponseHead::UpdateHeaders should probably not restrict Last-modified.

Revised patch coming up.

Comment 4

[Darin Fisher]

Attachment: v1.1 patch

seeking additional review from biesi since i added an extra change to the patch.

Comment 5

[Steve England [:stevee]]

Is there a bug filed on the "initial problem with the heuristic calculation using the Date and Last-Modified header from different requests."

Comment 6

[Darin Fisher]

fixed-on-trunk

Comment 7

[Darin Fisher]

Comment on attachment 227319 [details] [diff] [review]
v1.1 patch

I think it'd be good to fix this bug for FF2

Comment 8

[Peter van der Woude [:Peter6]]

any chance this caused bug 343282 (uneducated guess) ?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Darin: are you going to land this on the 1.8 branch?

Comment 10

[Darin Fisher]

fixed1.8.1

Thanks Gavin for the reminder!