default_ttl applied even when Expires exist
ric at digitalmarbles.com
Mon Apr 21 02:47:13 CEST 2008
On Apr 20, 2008, at 12:28 PM, Ricardo Newbery wrote:
> On Apr 20, 2008, at 2:44 AM, Ricardo Newbery wrote:
>> Noticed some odd behavior.
>> On page with an already-expired Expires header (Expires: Sat, 1 Jan
>> 2000 00:00:00 GMT) and no other cache control headers, a stock
>> of Varnish 1.1.2 appears to be applying the built-in default_ttl of
>> 120 seconds when instead it should just immediately expire. There is
>> nothing in the vcl doing this so it appears that Varnish is just
>> ignoring the Expires header.
>> Can anyone else confirm?
> Answering my own question.
> 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.
> The solution to this -- assuming you can't change the backend
> behavior -- appears to be to manually set a default_ttl = 0. Are
> there any potential issues with this solution?
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
At least one backend I'm familiar with uses an already-expired Expires
date as a shorthand for "do not cache" and it seems that this is valid
behavior according to RFC 2616.
From RFC 2616 (14.9.3),
Many HTTP/1.0 cache implementations will treat an Expires value that
is less than or equal to the response Date value as being equivalent
to the Cache-Control response directive "no-cache". If an HTTP/1.1
cache receives such a response, and the response does not include a
Cache-Control header field, it SHOULD consider the response to be
non-cacheable in order to retain compatibility with HTTP/1.0
Even in the case of a "clockless" origin server, RFC 2616 allows for a
past Expires date,
From RFC 2616 (14.18.1),
Some origin server implementations might not have a clock available.
An origin server without a clock MUST NOT assign Expires or Last-
Modified values to a response, unless these values were associated
with the resource by a system or user with a reliable clock. It MAY
assign an Expires value that is known, at or before server
configuration time, to be in the past (this allows "pre-expiration"
of responses without storing separate Expires values for each
More information about the varnish-misc