-----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----- _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev