If-Modified-Since

Geoff Simmons geoff at uplex.de
Wed Feb 23 22:14:54 CET 2011


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

On 2/21/11 11:02 PM, Artur Bergman wrote:
> 
> On Feb 21, 2011, at 10:07 AM, Geoff Simmons wrote:
> 
>>>
>>> ttl=0, grace=0
>>> 	This is a clear cut expiry, but we may still catch it before the
>>> 	grim reaper does, we should explicity make sure we do not.
>>
>> OK, we don't have anything to check for this case, so in our current
>> code it might in fact pick up such an object. All right, then we'll
>> explicitly rule this out.
> 
> Why?
> 
> I might want to force a IMS to the backend without having ttl or
> grace. You can set the conditional timeout to 0 if you really want it gone.

My understanding of phk's point here is that setting both TTL and grace
to 0 is a way of deciding in VCL to remove an object from the cache.
Such an object will be evicted the next time the heap is re-organized.

If you set obj.ttl = 0, then obj.grace is implicitly also set to 0,
because this is expected to make the object no longer cacheable. If you
don't want that, then you have to explicitly set a non-zero obj.grace.
Setting obj.ttl = 0 is the basis for the sample VCL code in the Wiki for
implementing a PURGE method.

@phk: If we also implicitly set obj.conditional_timeout = 0 when obj.ttl
is set to 0, wouldn't existing VCL continue to do what people expect? I
think Sky has a point here, if conditional_timeout > 0 while TTL and
grace are 0, it would mean that an object shouldn't be used for grace
(another object is busy or the backend is sick), but could be used for
IMS requests. If we're not breaking everyone's VCL, why not make that an
option?


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/

iQIcBAEBCAAGBQJNZXjNAAoJEOUwvh9pJNURHyoP/j7gOtgtd1r2BjjI7yKjI1Xj
wpROBavXMQfHaLQLHnFWFMz9ceUsBgkRmg+jydl8K/WA8t/zPPVs8vT0wYUQuomg
ZmndPwYSsEKFwTJ4mhreHJLTC17bGUy7Ied0bzs80YmSD5CDR19PVig4FT/U7Tew
DfcNWe/6ZPiv4B6WKO5LBvduL3zCqzLVH2IMKrmm5UIuvWJigPfl//SREAcpefiT
HdAA4iRCbIcnt314pAnxG9uHHtXG++S1PM2rEXCG6gvvXjsEvTjY0EHvqsFadotZ
3stELcKAB2jsoAdNpyB2swxy3AOVryLUVIHRWnY/ZA6IUiHXItg85KlSSO26RudT
gLj8k78N89gkTCRe3Gp1nvaE8p5SwerLmwi6119Sdfpj/IelH1JZKBSfNpzH2Zbm
A5VNU9uvDzScSWw4WDyVVOlB7l0k40q0Uhv/n0D5X1JvwaXojunPFPp96JACRmDD
6OGYwoLERz+sSiBlSjOc3cB5kru0ascRx0BqjtyaVACGWTL71bITCmW/gFjCkZAg
Bk0Wcfk6YLdQnLGPnacnvHN9MsZp5ecoMUDW9a5/0xMhj3PLfvtLxQMk388zEsIz
6b6jMqN6xHmxPXKrqiZPO8d+maVVMVlgZbBnXZsoUYl4UCN7JK6cqm8mVTgkwmDc
9M6HgRRiQ6EC8rCfGJVy
=syd/
-----END PGP SIGNATURE-----




More information about the varnish-dev mailing list