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=zero&banner=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.
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 yastrakhan@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=zero&banner=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
Hi Yuri,
On Jun 14, 2013, at 7:16 PM, Yuri Astrakhan yastrakhan@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=zero&banner=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.
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
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
wikitech-l@lists.wikimedia.org