Page MenuHomePhabricator

Background image of login page is served with a short TTL
Open, Needs TriagePublic

Description

https://gerrit.wikimedia.org/r/login/ has a a background image 2006-12-28_10h26_33.jpg served by Gerrit a static asset. Per documentation at https://gerrit.wikimedia.org/r/Documentation/config-themes.html :

Assets under '$site_path'/static whose file name matches one of the following patterns are served with a 1 year expiration, permitting very aggressive caching by clients and edge-proxies:

*.cache.html
*.cache.gif
*.cache.png
*.cache.css
*.cache.jar
*.cache.swf

All other assets under '$site_path'/static are served with a 5 minute expire, permitting some (limited) caching. It may take up to 5 minutes after making a change, before clients see the changes.

1024px-Sea_and_sky_light.cache.jpg was the previous image which was replaced via https://gerrit.wikimedia.org/r/c/operations/puppet/+/471281 . The new image lacks the cache.jpg suffix

https://gerrit.wikimedia.org/r/static/2006-12-28_10h26_33.jpg is served with:

`Cache-Control: private, max-age=900, must-revalidate

Then if I query https://gerrit.wikimedia.org/r/static/wikimedia-codereview-logo.cache.png it gets served with the same 900 seconds max age.

Thus the documentation is obsolete.

Event Timeline

Mentioned in SAL (#wikimedia-operations) [2025-04-23T12:27:27Z] <hashar> gerrit: removed obsolete 1024px-Sea_and_sky_light.cache.jpg file from all servers. File was replaced by 2006-12-28_10h26_33.jpg # T392479

The one year max age is only set when one requests a static file with the e parameter set to an ETag matching the requested file. Eg:

Request file:

$ curl --head https://gerrit.wikimedia.org/r/static/2006-12-28_10h26_33.jpg
ETag: 71b69c6750d7b47cb1b9051134d746b5
Cache-Control: private, max-age=900, must-revalidate

Request it again passing the received etag as query parameter:

$ curl --head https://gerrit.wikimedia.org/r/static/2006-12-28_10h26_33.jpg?e=71b69c6750d7b47cb1b9051134d746b5
Cache-Control: private, max-age=31104000

It looks like a remnant from the original implementation of ETags and I guess the code was simply not removed.

I have sent a couple patches upstream to update the doc and remove the e parameter which has no usage in the existing code.