The zero ESI change is now live, but is enabled only when X-FORCE-ESI
header is set to "1". Also, it won't work until varnish enables ESI
support for zero requests (see
)
I propose the following deployment steps:
1) set beresp.do_esi = true for all requests with X-CS header. (should not
be enabled for javascript or any other non-html resources)
This will let us measure ESI impact when HTML has no <esi:include> tag.
2) Enable X-FORCE-ESI header for one or more smaller carriers while
monitoring the impact on varnish load
3) Enable ESI configuration flag for all zero partners
4) Remove cache variance on X-CS header
On Tue, Jun 18, 2013 at 12:06 PM, Yuri Astrakhan
<yastrakhan(a)wikimedia.org>wrote;wrote:
Hi Mark,
On Tue, Jun 18, 2013 at 11:58 AM, Mark Bergsma <mark(a)wikimedia.org> wrote:
* All non-local links always point to a redirector. On javascript
capable
devices, it will load carrier configuration and
replace the link with
local
confirmation dialog box or direct link. Without
javascript, redirector
will
either silently 301-redirect or show confirmation
HTML. Links to images
on
ZERO.wiki and all external links are done in
similar way.
For M, you only want to do this when it's a zero carrier I guess? If not,
just a straight link?
Correct - two variants for M -- with ESI banner + redirect links, and
without ESI
+ direct links.
* The
banner is an ESI link to */w/api.php?action=zero&banner=250-99* -
returns HTML <div> blob of the banner. (Not sure if banner ID should be
part of the URL)
I'm wondering, is there any HTML difference between "M & isZeroCarrier ==
TRUE" and "ZERO"? Links maybe? Can we make those protocol relative
perhaps?
We might be able to kill the cache differences for the domain completely,
while still supporting both URLs externally.
Yes - M+Carrier -- has images, ZERO -- redirect links to images