what is the ttl?

[Poul-Henning Kamp]

--------
In message <53FCCB1D.5070707 at schokola.de>, Nils Goroll writes:

>We now have the situation that the ttl actually starts at the point in time
>corresponding to Age, so if an object with "Age: 120" and "max-age=180" is
>received from a backend, by default, it will only have one minute left to live
>in cache.
>
>While this makes perfect sense for the default rfc2616 ttl, we get the same
>behavior when setting the ttl explicitly. With this VCL
>
>        sub vcl_backend_response {
>                set beresp.ttl = 120s;
>	}
>
>if the received object has "Age: 60", it will get cached for one minute only.

I think this is wrong.  If you set the ttl, it should be "ttl from now".

>What might be even more confusing is the fact that reading the ttl a second
>later in vcl_hit will give 59 (seconds remaining in cache).

This is correct.

>If Age is larger than the ttl we set in VCL, the object won't get cached at all.
>I think we should make this consistent and easier to understand.

So this is a point I've been pondering.

It used to be that we respected the beresp.ttl for delivery decisions,
but we have other ways of saying "don't deliver the object just
fetched" now.

So now we should probably always deliver the fetched object, no matter
what beresp.ttl is set to.

>One simple idea to regain consistency would be to make a "set beresp.ttl" do
>what a read on obj.ttl gives us: the time remaining in cache (ie add the Age to
>the internal ttl).

Yes, it's a bug that it doesn't.

>In addition to that (or even replacing the VCL ttl) I like the idea to add two
>(additional) variables:
>
>* (beresp|obj).age : corresponding to the Age header, the current Age
>  of the Object

This may not correspond to the Age: header, but we can return the
value of (now() - exp.t_origin) which would almost always be the
same thing.  (We don't store the unadultered age)

>* (beresp|obj).maxage : directly access the internal ttl, irrespective of
>  age

I don't understand what "internal ttl" means ?

I also fear confusion with respect to "max-age" in Cache-Control:

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.