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 dochttps://www.varnish-cache.org/docs/3.0/tutorial/esi.html )
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@wikimedia.orgwrote:
Hi Mark,
On Tue, Jun 18, 2013 at 11:58 AM, Mark Bergsma mark@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