Identified via https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMain_Page&tab=mobile, I was surprised to find a versioned load.php url among the list of urls with no expiry or a short expiry.
Given our current platform, I expect to only find thumbnails (no expiry), skin stylesheet (5 minutes) and the startup module (5 minutes) in that list, but instead also found:
- https://en.m.wikipedia.org/…er.defaults&skin=minerva&version=15glgu9 (5 minutes)
For that test, the full url was:
Which currently responds with:
This is expected behaviour when a url is constructed with a version parameter that doesn't match the current version by the server. The server only has the current versions of static assets and will respond with those as such, but we don't want to cache them under the "wrong" url for too long.
This was implemented to address T117587 (6fa1e56), which is the problem where during a deployment, a user can get module meta data from server A (with new code) and then construct its versioned url client-side and fetch (this time to server B; with old code still), at which point we don't want to popular the Varnish edge cache with the "old" content under the "new" url version.
However, I don't understand why the client is requesting the wrong version in this case. It doesn't appear to have changed recently.
Additionally, I did verify to see if this may be a bug with any of the individual modules (e.g. oscillating version, or unmatchable/non-deterministic version hash), but that wasn't the case. If I request the same url with the etag version in the query parameter, then I get the correct response headers.
cache-control: public, max-age=2592000, s-maxage=2592000