IMS: grace & keep

[Geoff Simmons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Poul-Henning,

I'd like to make sure that we have a common understanding about the
grace and keep intervals for backend conditionals. In particular, IIUC
an object that is still in grace can be a candidate for an IMS request.

Shortly after VUG you wrote:

> ttl=0, grace>0
> 	This is a special case, where the object is expired, but still
> 	available for grace (you have to first set obj.ttl = 0 and then set
> 	obj.grace to nonzero, as obj.ttl = 0 also clears obj.grace)
> 	I think in this case it is a candidate, the admin clearly considers
> 	the content valid enough to use in an emergency, so it should be
> 	fair game for IMS also.

So: if TTL has elapsed, but Varnish finds an object in grace, and
decides as it does now to serve it from cache, then it does so;
otherwise Varnish uses it to attempt the conditional request (if the
object has the headers for it).

That would mean that setting keep = 0 does *not* switch off backend
conditionals, if grace is non-zero. keep = 0 just means that the
interval in which IMS can take place is not extended any longer than
grace. The only way to prevent backend conditionals altogether would be
in VCL, by removing the IMS and INM headers from bereq.

Is that what you hand in mind?

That last part tripped me up, because I was testing with keep = 0,
expecting IMS requests to be switched off, but they were happening
anyway (which is why I thought I had a bug). It turns out that it was
the objects in grace.

I think it would be fine for Varnish to work that way (and it's nice to
not have a bug for once), but it should be documented clearly, so that
others are not as confused as I was.


Best,
Geoff
- -- 
UPLEX Systemoptimierung
Schwanenwik 24
22087 Hamburg
http://uplex.de/
Mob: +49-176-63690917
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNe6u+AAoJEOUwvh9pJNURS8QP/RnLLqUdAPBTDFkNjz2jEOY/
khCW37md+T5Lu8GkL5y6+ueX00AUDEzsWFNkzL6nmk525UyUURxCUWISYXKNTpeT
lm8TDarzH1HHTuZHhZqJ0Z2Gzy/5dp7UevxzY6d53iN/mjQt/4x3hL4S/EiEngBX
YvwDaKS5xlfEWlUZ4xI3X5s6hWTiK2GdkNwhAQwnLox43NwuU/yoCeuN+tMkYWhU
GV/X65ueUCwJ9e/CtP6P7ij+Sk/eWUx3KSdMqKB9Oi914gI3CZFmpdV+WLdDe4SP
dtJYuqgxiuwHEokRsdC6VjhnxoKXBUwo0QGNY9Gmi4rDo+LhM0qNxKiRnTeBvu4t
Eyhwe4HpkESdbh8KvwMCnQzMmSC+zbIMnuTYQ6Y92B6/JI8HgWKDLt2DPObl0O1j
W3mgoqJCz2NDN2tWFt/K9EN92upIYquISxEges24mMRZUXWyw9oIcnFT0ITW6Jlf
ogXaJBF+cluILFQRO1ubv6XYEZF6qq0jM3Otav8pVtwTBWpFpRLN/qVVdGF1Fy5D
E+SO+YOyHcmFuZwJSSlYpHEBZECPxTdIwOcxqfzyQB3bhEt+ANySE71PmWErKC98
h8hQrA6HEMSp4f1SjZO/zwiD7jIWpLtrVNahml+hdl5Tk2qrxqhcUD9xkG3RfGoi
d76Zk2gi3AUqHPn8LbP2
=Dd9Q
-----END PGP SIGNATURE-----