Last modified: 2013-12-10 22:04:16 UTC
We've discussed this issue with Yuri a few times now but we've failed to track & communicate this properly, so let's try using a bug tracker :) Currently, Varnish handles "m.wikipedia.org" and "zero.wikipedia.org" in a special way, issuing redirects and having logic on where to direct those redirects based on the carrier value and other information inside the Varnish config. This is basically unmaintainable and a hack in how Varnish is positioned in our infrastructure. It's also a duplication of config between MediaWiki & Varnish and one that needs to go through the painful process of submission by the zero team + review & approval by ops to get deployed. MediaWiki already has all the information of issuing such redirects based on internal information known about the carrier. Hence, we have proposed that application servers should handle the "m.wikipedia.org" & "zero.wikipedia.org" domains as-is and MediaWiki should issue the needed redirects or -even better since redirects cost in latency- a proper landing homepage suitable for both zero & non-zero normal mobile clients altogether. This redirect or homepage should not be language-specific (e.g. an en.m redirect like initially proposed) and could be in content similar to how "www.wikipedia.org" is structured. It can also Vary: X-CS, so we can cache a separate version per carrier. We've requested this change for many months now and we were operating under this assumption this would be part of the netmapper deployment. netmapper got deployed last week, however the above did not happen and this has resulted in an even more complex Varnish config than before, instead of a vastly simplified one like we were expecting. This presents maintainability problems to us and we would like to see it fixed ASAP.
After going through multiple revisions trying to have a regular page showing as m.* or zero.*, I realized that it would be too destabilizing and complex to do right, so I am going back to the redirect route. The m. and zero. would redirect to the correct lang.m or lang.zero depending on the carriers setting. The code is almost complete, and should be ready for deployment within a week.
This is done.
Correction, we need to update the VCL....
VCL has only stuff to do with fragmentation. The starting page has been resolved.
