HomePhabricator

varnish: Don't disable Cache-Control for all mobile traffic

Authored by Krinkle.

Description

varnish: Don't disable Cache-Control for all mobile traffic

Mobile-frontend traffic is currently overwriting Cache-Control on all requests.
One branch preserves some small amount of s-maxage (for third-party proxies, no
idea which or why). But both branches of this code disabled "max-age" which is
what browsers use.

The end result is that it forbid browsers to ever use local cache for load.php
requests. Since there is no "no-store" pragma here, browsers do still store it
for a short period of time. But much shorter than the otherwise-allowed 30 days
and since it has max-age=0 and must-revalidate the browser is forced to
rerequest all resources on every page view (usually getting "304 Not Modified").

This code appears related to the s-maxage stripping we have in text-frontend
(which exists to counter-act $wgUseSquid, which is only desired within the data
centre, not outside). However I'm not sure it really is that since it didn't
set it to 0 but to 300.

This code was introduced in 2011 with e1e13ed3d6. It wasn't a problem then
because we had load.php on bits.wikimedia.org. In May 2015 we migrated bits
to wiki domains. But mobile pages accidentally got configured to use load.php
from the desktop domain. Last month we fixed that (T106966) and the inevitable
finally happened. That switch increased load.php traffic by 30% from ~ 1.1M
to 1.4M reqs/minute. And it raised HTTP 304 ratio from under 1% to over 60%.

Bug: T113007
Change-Id: Icbcc04efaff41134bd406cf498e062c7edf41956

Details

Committed
oriSep 21 2015, 6:16 PM
Parents
rOPUP52d1bd3605f4: remove mw1031 from dsh groups and DHCP
Branches
Unknown
Tags
Unknown
References
refs/changes/26/239826/2
ChangeId
Icbcc04efaff41134bd406cf498e062c7edf41956