-----BEGIN PGP SIGNED MESSAGE-----
On 3/23/12 4:11 PM, email@example.com 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
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
22087 Hamburg http://uplex.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
varnish-dev mailing list