Re: [Wikitech-l] The summary of new zero architecture proposal
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 yastrak...@wikimedia.orgwrote: Hi Mark, On Tue, Jun 18, 2013 at 11:58 AM, Mark Bergsma m...@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=zerobanner=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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The summary of new zero architecture proposal
Hi Yuri, On Jun 14, 2013, at 7:16 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: Based on many ideas that were put forth, I would like to seek comments on this ZERO design. This HTML will be rendered for both M and ZERO subdomains if varnish detects that request is coming from a zero partner. M and ZERO will be identical except for the images - ZERO substitutes images with links to File:xxx namespace through a redirector. * 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? * The banner is an ESI link to */w/api.php?action=zerobanner=250-99* - returns HTML div blob of the banner. (Not sure if banner ID should be part of the URL) Expected cache fragmentation for each wiki page: * per subdomain (M|ZERO) * if M - per isZeroCarrier (TRUE|FALSE). if ZERO - always TRUE. 3 variants is much better then one per carrier ID * 2 per subdomain. 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. -- Mark Bergsma m...@wikimedia.org Lead Operations Architect Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The summary of new zero architecture proposal
Hi Mark, On Tue, Jun 18, 2013 at 11:58 AM, Mark Bergsma m...@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=zerobanner=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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] The summary of new zero architecture proposal
Based on many ideas that were put forth, I would like to seek comments on this ZERO design. This HTML will be rendered for both M and ZERO subdomains if varnish detects that request is coming from a zero partner. M and ZERO will be identical except for the images - ZERO substitutes images with links to File:xxx namespace through a redirector. * 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. * The banner is an ESI link to */w/api.php?action=zerobanner=250-99* - returns HTML div blob of the banner. (Not sure if banner ID should be part of the URL) Expected cache fragmentation for each wiki page: * per subdomain (M|ZERO) * if M - per isZeroCarrier (TRUE|FALSE). if ZERO - always TRUE. 3 variants is much better then one per carrier ID * 2 per subdomain. P.S. Redirector is a Special:Zero page, but if speed is an issue, it could be an API calls (which seem to load much faster). The API call would redirect to the target, or could either redirect to the special page for confirmation rendering, or output HTML itself (no skin support, but avoids an extra redirect). Might not be worth it as javascript will be available on most of our target platforms now or soon. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The summary of new zero architecture proposal
I think we'll want to make those 302s given that UAs may make the redirects permanent without consideration for Vary: headers, some of which the UA won't actually know. Will add that to the RFC shortly. On Fri, Jun 14, 2013 at 10:16 AM, Yuri Astrakhan yastrak...@wikimedia.orgwrote: Based on many ideas that were put forth, I would like to seek comments on this ZERO design. This HTML will be rendered for both M and ZERO subdomains if varnish detects that request is coming from a zero partner. M and ZERO will be identical except for the images - ZERO substitutes images with links to File:xxx namespace through a redirector. * 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. * The banner is an ESI link to */w/api.php?action=zerobanner=250-99* - returns HTML div blob of the banner. (Not sure if banner ID should be part of the URL) Expected cache fragmentation for each wiki page: * per subdomain (M|ZERO) * if M - per isZeroCarrier (TRUE|FALSE). if ZERO - always TRUE. 3 variants is much better then one per carrier ID * 2 per subdomain. P.S. Redirector is a Special:Zero page, but if speed is an issue, it could be an API calls (which seem to load much faster). The API call would redirect to the target, or could either redirect to the special page for confirmation rendering, or output HTML itself (no skin support, but avoids an extra redirect). Might not be worth it as javascript will be available on most of our target platforms now or soon. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
