-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/23/12 4:11 PM, [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.
To be sure I understand your argument, are you saying that in the "almost-always" case, headers from the 304 response do not in fact change anything about the refreshed object, so we could continue using it without any of the copying or refcounting? Or that some information about the object could be safely updated, despite the general rule that objects in cache are never modified? The quotation above sounds something like the latter, but if I read you right: convert Expires to a uint64, which can be updated in the cached object, and convert it back to text form on delivery. It seems worthwhile to check for the case where the 304 response doesn't change anything -- then we could continue to use the old object, update its TTL etc., and discard the new object created from the beresp. But I'd be cautious about anything that involves updating the old object, and that's the general answer to your question -- we don't want to break the rule that objects in cache are not modified. Your questions about this make sense, on first blush you wouldn't expect validating requests to get involved in things like storage and stevedores. If the common case can avoid that, I'm all for it, although we'd still need the capability for the unusual case, since 304 responses could contain any headers at all. But we can't do this in a way that breaks the concurrency model, that would cause disruptions that would be far worse and certainly not worth it. 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/ iQIcBAEBCAAGBQJPcCmSAAoJEOUwvh9pJNURlScP/3hNxrkjSjP5jwgRPxlXKVOb Ro9lL2TMfX2qHcKGVLzvB/0uBqZgW9Iy4jqUydZRZlMdUXEMsVWfQQyBx7I1xy0t e9UcAveFyeXcsGkXfVcTDDTi09CrCDbbxanhpm4kaGTY3jjjqNh5EfQByYwwI8D7 MzdiKJ0k5tZtRlIjbhAkJ8XfDZkUhJzXA7ypV6tHnB8/jDv3K8Fj+ihTsIbGrAh+ PpSR5vpt9wi2b8S5Ujz/0BvZEW7pW+OpF0BXs4e8/dSIqEu1OOSwl7AnN964qjKf qK4UOSCNCZRJ8qGfn/PuGO8YnRBXtoXqbtGU1h2Kjhnk7sEUCQ5Ys3b1ytV0ckId WMKH8pT+fq1/08FNnQBj8VQyLAcfsqnFj38q/3h9wzUMx+V0b60eUXhRazv0yXOZ hAhEUR/CvxXaHoK3gBnbdR4FC0BHU5Ut8oUeYtpxbonjePVQINa34Ck2Sljxm3ay J0hECr5g2new59e3QT0H66dKG9RkBUkJPsASpi3weGMtPpMSDSFxLNJZ0sYD231C PfsdoCLQ4/qI9tOKSqXXSD/eBwkrW1awrA3ROfeeSIn8QUXYftUywfzamShYMpVw qBtKyVxFXw3Ey1ylE9mgd0QCWQloFvsbcPa8Z03Rwboo0SawKvpEjNv5uVizNqR8 uxzbZPO61RIuq5X5dxcj =6Dto -----END PGP SIGNATURE----- _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
