hit-for-pass vs. hit-for-miss

[Geoff Simmons]

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

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
VCL.

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.


Thanks,
Geoff
- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

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

http://uplex.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXydFUAAoJEOUwvh9pJNURK6EP/As7G39CCizW+wHaTGaXbq2w
JjzXRpMPgnsmlTZ24PjUh/e+kih9PxXgBruQdsZ0egMIlQN3tXI77ZyOol0oFfBk
TspB1ANGPw95JS4rTRx4PtTCPHlfXtyY+b07T/QRGRmKkosxOBDVJrtEaQ2xaJ88
GF0p208GROf3VFYtQ05QYfwvyiwX09dopEQmMyrEdkoq9uH3Xrf1d5FWT5OYbEFy
LMHtoRkdVp78qt4hgV8LYG1BJ4AYRKOhbIIVlX7itw12PZuMNoAf+Z+r4RzQX74t
a0fAPkwvkym3XxfxhPu9CceEsKoTOb+zMOUV2+GNO1NP7r25xLRCJ62zoQHzpKs4
SacB2zcecRVnw+/WYtlxseSmUbmzizZu3MLyiCIBlCsTIktgZOMlrUP4++WFckY7
C4uuqd2OrxyhzHTP7BBVSr9+itITU1tNGWE87wZy7yOh9ITb9YFd9esVStTqyItd
fb0Ps+yqaqfxZHDpo+vOh1RIc+GPzSBxt9eDd0nPWBFFjLyr74/gCjYOh12oxwUK
j+gkO31mmfy9umw0bUvF9ZLGytnOGVD0hFVuAQ8DcRt1cGvPOl87nwr5iRXtTxPP
O/4qbrgy66X98kWkB3A+eaCzG1WobinNvwfrsxRkF1FpFXi5xmCVmjSRaF1S6hOW
/IY8lsypBwb5CX7fCvsh
=1Siq
-----END PGP SIGNATURE-----