hit-for-pass vs. hit-for-miss
geoff at uplex.de
Fri Sep 2 21:21:56 CEST 2016
-----BEGIN PGP SIGNED MESSAGE-----
On 09/02/2016 08:10 PM, Nils Goroll wrote:
> - varnish is running in "do how the backend says" mode - backend
> devs know when to make responses uncacheable
Just so that you know what that's all about, to understand the use case:
We have a project at which TTLs for caching are determined almost
exclusively from Cache-Control (there are some exceptions, but that is
far and away the most common case).
This means that we run Varnish with -t 0, and set beresp.ttl=0s if
neither of Cache-Control or Expires are present in a response. So
setting a TTL for caching is entirely the responsibility of the devs.
That means in turn that we do not have long sequences of regexen in
vcl_recv to decide: lookup for these and pass for those. I'm sure
everyone knows how unmaintainable that sort of thing can become, and
for us, it's absolutely out of the question. There are far too many
dev teams, choosing and changing their URL patterns all the time, we
could never keep the patterns up to date, nor do we want Varnish to do
all that regexing on every request.
If you think about it, this is the way the world should be -- devs are
fully responsible for setting TTLs with Cache-Control.
But what that means is that we have no way of knowing in advance which
requests will be passed -- meaning, we don't know it in vcl_recv
solely on the basis of the client request. I'd have to check, but it
wouldn't surprise me if "return(pass)" does not appear anywhere in our
Setting beresp.uncacheable is the only way we can determine that
subsequent requests for the same URL can be passed.
That leads us to the problem that Nils described -- prior to the
change that he mentioned, requests with bereq.uncacheable were pass,
so req headers were filtered into the bereq as in the pass case. In
particular, conditional headers (IMS/INM) were not filtered out. "If
the client asks for validation, and we're passing, then we ask the
backend for validation, and if the backend says 304, pass it along."
After the change, requests with bereq.uncacheable are misses, so the
conditional headers are filtered out.
So our situation now is:
* Setting beresp.uncacheable is the only way we can know that a
request can be passed.
* But now it has become impossible to pass along conditional requests
under these circumstances, even if both the client and backend are
able to everything right with IMS/INM and Last-Modified/ETag.
I'll let Nils' mail describe the rest. What we're missing now is: set
up the bereq for pass, in particular allowing the conditional headers,
not because we've set it to pass in vcl_recv (which we can't do), but
because we've set beresp.uncacheable for a previous beresp.
** * * UPLEX - Nils Goroll Systemoptimierung
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the varnish-dev