Agreed, but if you change Cache-Control, and an Expires exists on the obj, you must also change that, or the client may not cache the entity because of a past dated Expires header. The trouble with Expires is that it states an absolute point in time for the expiry, versus Cache-Control with is treated relative to the Date: of the delivery.
One solution I have used is to not actually change the Expires header in the cached object (no no issues with locking), but instead dynamically rewrite the Expires header upon delivery in accordance with the difference between the generated Date: header and the max-age parameter from Cache-Control. This way the Expires and Cache-Control headers always agree. Adrian On Mar 23, 2012, at 8:11 AM, [email protected] wrote: > Only if people change the cache-control. Expires could be turned into a > uint64 and safely updated, though expires is generally frowned upon. > > Artur > ------Original Message------ > From: Nils Goroll > To: Artur Bergman > Cc: [email protected] > Subject: Re: VUG5 IMS presentation > Sent: Mar 23, 2012 08:09 > > Hi Sky and all, > > I really should have sent a brief note on what was discussed at VUG5 today: > > All the slides on VCL access to the stale_obj etc. were are really only meant > as > a basis for the discussion we had. My understanding of the consensus is that > IMS > feature should first go in as a minimal solution: In vcl_miss, you could drop > the If-* headers if you wanted to disable IMS, otherwise it would just be > implicitly enabled. obj in vcl_fetch would be the new object created from the > 304 response with any missing headers copied from the stale object. > > If needed, the stale object could be made accessible through a vmod and if we > found actual use cases for this in real world projects later, we could still > agree on inclusion of access functions in VCL. > >> If you get a 304 and no headers have changed (most likely) then you don't >> need to copy the object, just update timestamps. > > It is important to update Expires/Cache-Control to "extend" the lifetime of > the > refreshed object ( > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 ). We must > not > change a live object header because it is not protected (by locks). So we > really > need to have a new object and dup (either reference or copy) the body. > > Nils > > Sent via BlackBerry by AT&T > _______________________________________________ > varnish-dev mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
