default_ttl applied even when Expires exist

[Ricardo Newbery]

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  
>> install
>> 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?
>>
>> Ric
>
>
>
> 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?
>
> Ric
>
>


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?

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  
servers.

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
    resource).

Ric