[PATCH] Surrogate-Control (max-age) support

[Geoff Simmons]

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

On 09/18/2014 08:58 PM, Federico Schwindt wrote:
> 
> I had some time on the plane today so here's a quick stab at
> getting Surrogate-Control support as discussed during the vdd.
> Disabled by default. Only max-age is supported with this patch.

We had some discussion about this in IRC, which I'll try to
recapitulate here.

My concern was that someone may already be using Surrogate-Control to
target a proxy that is downstream from Varnish. That would be broken
by the patch, since it unconditionally strips the header from the
response.

I believe we came around to a consensus to implement targeting, as
described in section 2.3 of http://www.w3.org/TR/edge-arch, so that
users may be able to target the S-C header to Varnish and/or another
proxy.

- - Varnish has a default token name, which may be overridden by a param
like: -p surrogate_token=<token>

- - When the feature is enabled, Varnish appends a
Surrogate-Capabilities request header, identifying itself with the
token, e.g.:

Surrogate-Capabilities: <token>="Surrogate/1.0"

The header is added if not already present in the request, otherwise
this value is appended to the existing header.

- - The Surrogate-Control response header is honored for the part that
targets the Varnish token, or for any part that contains no token, if
Varnish is not specifically targeted.

So a response may include:

  Surrogate-Control: max-age=60+30;myvarnish, no-store;mycdn

That would mean: the "myvarnish" instance of Varnish sets TTL=60 and
grace=30, while the no-store directive is targeted to "mycdn".

This would have the same effect (assuming the token is "myvarnish"):

  Surrogate-Control: max-age=60+30, no-store;mycdn

In that case, no-store is targeted to "mycdn", and the max-age
directive is targeted at any other proxy, and is therefore honored by
Varnish.

- - What exactly should the default token name be? That subject is ripe
for bikeshedding, so we can have a long, passionate discussion about
it, or just set it to "varnish", or to the value of server.id.

- - We can also evaluate no-store (fgs' patch just honors max-age for
simplicity, but no-store shouldn't be too hard).

- - Honoring no-store-remote should be a matter for VCL, since Varnishen
are not typically "remote" proxies.

- - All of this should be overridable in VCL.

- - MAYBE we remove the S-C response header if Varnish "consumes" it.
The TR says in section 2.2: "If no downstream surrogates have
identified themselves, the header should be stripped from responses."
Assuming that the lower-case "should" is just like an RFC SHOULD, we
can remove the header if no other downstream sent a
Surrogate-Capabilities header.

Since this is a "TR" and not a formal standard, and since it shows a
little sloppiness in some places (inconsistent spelling of the request
header, out-of-order numbering of chapter headings, examples that
don't match the prose), IMHO we don't need to be strict about
conformance. We can document the feature as "in partial fulfillment
of" and then describe exactly what it does, which is I think is good
enough for what we need: setting a TTL (and possibly grace) for
Varnish, without passing the same setting downstream (as is necessary
with Cache-Control and Expires).


Best,
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.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUHBL5AAoJEOUwvh9pJNURkcQP/jmUJnWdXL/g6to2JBiWI69u
tHTzomMM3H7kpalOStVVbhB+dpjs96AvSTtUn1hnRQkwIVIyW2sL5l64On+gvEfN
2S3YMWf4H7Hm7u0BlL0bTedv+bGCXkv1sQC/AY0ZxTlB6LxuSvpJEXYSVSRpoitU
NY9GAFtRBPQ8cwOlxetiT720ZeZ+GZo2khy32xUrnkBihOVafWznxdfK+wVJX7EZ
3aLMnJxlW9efzMtWsWB1wtqHy3slHfYC+8h/O7AsNF0JJ6mXZxZoqKmsJAZkjT0N
oi1MNk0crRgI4T96V0bjCpsijndohMCpRgV9q3tDfRLjdVpLQqi7PuM01budqjqC
gZqsh9iAmrfEA7XjLYOxSygZwB1kyoJIhTg+Tl5nBQIg+qS+D/WfLemzj8pBueiy
zo4zakIljmNoNU0bWReoUetoTXrbSld5LtXqjzHcixkVtExRdOvhM5RfiehgpSNQ
dLOMhU5nNpm+rGbRt20kz8ufhyzdFfwx53FpMV/NQKXxaubAO3ePEQp3OQDMYGSQ
SJ3m5KZK0XXBDCIkXGjzc4hMniE8eejoldLdso+EmLRsCy5FihQZTPV/8OBhMTwS
YknLMgsXiXtCEwdWtded610C0cB4uNnrmA7GpILfGivd1g3WOMy07/obXb7Rbzy3
2QuMNkTPXZhQp3bgEOXc
=u3a0
-----END PGP SIGNATURE-----