default_ttl applied even when Expires exist

[Ricardo Newbery]

On Apr 20, 2008, at 10:33 PM, Poul-Henning Kamp wrote:

> In message <8240BA9F- 
> EAC7-4A9B-8128-265ABAD83B89 at digitalmarbles.com>, Ricardo N
> ewbery writes:
>
>>> I see in rfc2616.c that this behavior is intentional.  Varnish
>>> apparently assumes a "clockless" origin server if the Expires date
>>> is not in the future and then applies the default ttl.
>
>> Regarding this behavior.  I would like to suggest to the Varnish
>> developers that this logic seems faulty.  I guess it's reasonable to
>> assume a bad backend clock if the Date header looks off... but the
>> Expires header?
>
> That particular piece of code is taken pretty directly from RFC2616
> with addition of the default_ttl assumption.
>
> I'm not at all adverse to changing this code, provided we can agree
> what the correct heuristics should be.


Well, if I parse the pseudocode correctly, it seems to be claiming to  
do the right thing.  But the actual code following adds something  
extra to the heuristic which results in slightly different behavior.

Using the 1.1.2 release, lines 84-86 in rcd2616.c,

		if (date && expires)
			retirement_age =
			    max(0, min(retirement_age, Expires: - Date:)

But in lines 146-145, we have,

		if (h_date != 0 && h_expires != 0) {
			if (h_date < h_expires &&
			    h_expires - h_date < retirement_age)
				retirement_age = h_expires - h_date;
		}

Which appears to impose an extra requirement that Expires must be  
greater than Date.  Fix that (and enforce a floor of 0) and it seems  
like we can interpret Expires with a date in the past correctly.

Ric