https://bugzilla.wikimedia.org/show_bug.cgi?id=48835

--- Comment #3 from Faidon Liambotis <[email protected]> ---
We currently don't have a Client-Cache-Control header at all and I don't think
we should introduce it now with that name. Introducing just Surrogate-Control
and doing the VCL ping-pong you mentioned sounds more sensible to me. We'd need
a temporary header to store the client cache control, so we may end up using
Client-Cache-Control internally inside VCL as an interim header but I don't see
a reason for MediaWiki to use it. i.e. as I see it, the VCL could just be:

sub vcl_fetch {
  if (beresp.http.Surrogate-Control) {
    set beresp.http.Client-Cache-Control = beresp.http.Cache-Control
    set beresp.http.Cache-Control = beresp.http.Surrogate-Control
    unset beresp.http.Surrogate-Control
  }
}

sub vcl_deliver {
  if (resp.http.Client-Cache-Control) {
    set resp.http.Cache-Control = resp.http.Client-Cache-Control
    unset resp.http.Client-Cache-Control
  }
}

I don't see any handling that we do now to preserve the backwards compatibility
you mentioned. Even if we do and I missed it, we can easily implement it as
"else" clauses above, no?

It's a pity that Varnish doesn't natively support Surrogate-Control natively,
indeed. Ironically, Squid 3 does in some form :) (so using it inside MediaWiki
may be generally useful). I guess we could provide patches to Varnish for the
long-term but VCL hacks seem viable in the short-term.

Note that the standard specifies a Surrogate-Capabilities request header to
signal the capability to handle Surrogate-Control. We could set it in Varnish
and MediaWiki could check for it, so you may avoid a configuration option.

Also note that the same Surrogate-Capabilities/Control mechanism could be also
used to signal ESI back and forth (this is defined in the spec). Yuri has used
X-Force-ESI (request) and X-Enable-ESI (response) for this purpose in the
mobile caches for his ESI testing. We could deprecate those in favor of a
unified Surrogate handling by core, especially while we move in the direction
of doing ESI.

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

Reply via email to