If-Modified-Since

[Geoff Simmons]

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

Hello Poul-Henning,

Condolences on your laptop, I hope it will get well and you'll be back
up to full speed soon.

I'd like to recapitulate some of the results of our discussion at VUG
about backend conditional requests, to make sure that we have a common
understanding.

- - Instead of letting grace determine how long an object in cache can be
a candidate for conditional refreshes after its TTL elapses, we'll
introduce a new parameter for that. Let's say it's called refresh_ttl
(since I can't think of a better name right now). A global -p parameter
sets the default for all objects, and it can be set for individzal
objects. I'd guess that its default default value could be the same as
default_grace.

Nils and I think that the semantics should be like this:

  - In HSH_Lookup(), if an object o is found in the objhead list such
    that:
    - o->ttl has elapsed, but o->refresh_ttl has not elapsed, and
    - o has a Last-Modified and/or ETag header
    then o is a candidate for refresh (o becomes stale_obj).
  - a grace candidate is determined as it is now (independently of
    refresh_ttl)
  - the cache eviction time for an object (oc->timer_when) becomes
    o->ttl + max(o->refresh_ttl, HSH_Grace(o->grace))

That is, an object is evicted when grace or refresh_ttl has expired,
whichever is later.

- - As Sky pointed out, RFC 2616 Ch. 13.3.3 does indeed say that
Last-Modified is a "strong validator" only if Last-Modified from the
backend is at least 60 seconds before Date in the cache entry. But I
don't see any MUST or SHOULD requirement that applies to Varnish here.

The idea has to do with possible clock skew between different backends
that delivered the same object; and the RFC admits that the 60 seconds
is arbitrary. But since Varnish tries to account for clock skew, and
smart admins use NTP, I think we shouldn't worry about it.

Ch 13.3 of the RFC has a lot of interesting and generally unknown stuff
about the backend conditionals that we're not implementing. I wouldn't
worry about that either, but we might consider adding some features in
the future, for better compliance (and some of it might be useful).

- - For a first implementation, we agreed to put off decisions about
sharing storage between objects, until we're clear and how best to go
about it, and just copy the storage from the stale object to the new
object after a 304 response. Since I've encapsulated the duplication of
storage in STV_dup() and stevedore-specific dup methods, we'll just have
those functions copy the storage in all cases for now, and the
implementation can be changed later. (Nils and I intend to implement
shared storage for our private patch, which will go into production, so
we'll probably have some informative results.)

Comments?

It was good to see everybody at VUG, hope you're all doing well and
getting hit often. %^)


Best,
Geoff Simmons
- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Schwanenwik 24
22087 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNXXCWAAoJEOUwvh9pJNUReAMP/AzP/Je5fa3SFomg6UlBo6JS
WnVOHuYOkTjE6CXfKCEw0Eh6yPAkGsN1FuNN58uuWFfAI9MbdLQQGQ86Kr7wV7S1
gmQQxQB4Bod+nVHJn+apeQ9ZK1xX1x4/VHgedn2ZASLJoY4JKKR1mR5jy7Lbv43K
syrOPEoaabLPiTY4IydFhed7gDLv3GogvXH7RhWdfZh+rld0WrPtM4f/v8fFGRuA
XYMZTpPubTpFiKPtlHInZBq4MPUz3PPQPxVH0zQCQmVKzEkUGLuwLnPRG1YvZFtc
5pDPjFps5gLQdwA4geJxsL1cvwTYJlo6ZdAojZNVyTgUjK8YgFQxZB9S+Mg/B0BS
0p4WS6wDG5mXhxtXaC5n55u4cm07GLFxNX0947WZO0OGQc1INTyK1a/uRDMOTwd7
xBfHTA2C0EqU4xsxmB/FuYCOGwWBqoppFxRIo2hDXE4uuCxJfCywshYslGbUUfhs
j4I3Neo0J6zz4Urb0lSVbc9tcE8GUfuHApcu4BvRjjfCcqhTOkMGE9PmzA3Qb1uj
HOE2NqFWD64ztDNU2Vv0Erj0Nd77PygF5D3gBCK0HH171+IkT7ja+660W0qOp1Bu
nczTnz0OtB4krde6ZdmMafzIhiuj63ZgmCuJBEDJZLJRRijZGWFJ6aF2D4qnGsL5
HMSXOuEOyUpCfwcpVjWV
=bPnF
-----END PGP SIGNATURE-----