https://bugzilla.wikimedia.org/show_bug.cgi?id=48835
--- Comment #2 from Tim Starling <[email protected]> --- (In reply to comment #1) > We could do this the other way around and partially implement the > semi-standard (semi because it's from the W3C, not IETF) > Surrogate-Control header and leave Cache-Control intact for > end-users. Fastly, for example, seems to be suggesting users > to use this, so this may be a more compatible with the real world > alternative. Varnish uses the Cache-Control header in RFC2616_Ttl(), so I suppose it would be necessary to move the Cache-Control header out to some temporary pseudo-header in vcl_fetch, and to move it back into place in vcl_deliver. While the object is in the cache, Surrogate-Control would be copied into Cache-Control. Support for pass mode would theoretically be simpler with Surrogate-Control. Either way, there would have to be some backwards compatible handling in Varnish, to account for the progressive rollout of the new MW code. If Client-Cache-Control/Surrogate-Control is missing, Varnish would have to interpret Cache-Control in the old way. On the MW side, OutputPage could provide an interface allowing configuration of the mapping of headers: a) Old $wgUseSquid = false: * Client-Cache-Control -> Cache-Control * Surrogate-Control -> deleted b) Old $wgUseSquid = true; * Surrogate-Control -> Cache-Control * Client-Cache-Control -> deleted c) Surrogate-Control scheme: * Surrogate-Control -> Surrogate-Control * Client-Cache-Control -> Cache-Control d) Client-Cache-Control scheme: * Surrogate-Control -> Cache-Control * Client-Cache-Control -> Client-Cache-Control -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
