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

Geoff Simmons geoff at uplex.de
Fri Sep 19 13:26:49 CEST 2014

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

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

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

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

- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

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

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/


More information about the varnish-dev mailing list