what is the ttl?

[Nils Goroll]

Hi,

"our" Martin noticed confusing VCL behavior which relates to a bug and two
commits we have been discussing recently:

* https://www.varnish-cache.org/trac/ticket/1578
*
https://www.varnish-cache.org/trac/changeset/4e9fb4b339b7df0679609d699aa7f5c31aa32595
*
https://www.varnish-cache.org/trac/changeset/160927b690dd076702601b7407eb71bd423c62dd

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.

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

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.

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

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

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

Internally, (beresp|obj).maxage and (beresp|obj).ttl would use the same internal
ttl, so changing one would change the other.



Nils