default_ttl applied even when Expires exist

Ricardo Newbery ric at
Mon Apr 21 09:15:07 CEST 2008

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

> In message <8240BA9F- 
> EAC7-4A9B-8128-265ABAD83B89 at>, 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.


More information about the varnish-misc mailing list