Page MenuHomePhabricator

GitBlit main page sets Cache-Control: no-cache
Closed, DeclinedPublic

Description

We should leverage browser caching and a reverse proxy to make GitBlit responsive. It currently marks all responses as no-cache, which is too aggressive.

$ curl -I "https://git.wikimedia.org/"
HTTP/1.1 200 OK
Date: Sun, 09 Jun 2013 22:45:31 GMT
Server: Jetty(7.6.8.v20121106)
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Length: 1966389
Vary: Accept-Encoding


Version: wmf-deployment
Severity: normal
URL: https://code.google.com/p/gitblit/issues/detail?id=274
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51769
http://code.google.com/p/gitblit/issues/detail?id=274

Details

Reference
bz49371

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:04 AM
bzimport added projects: Gerrit, Upstream.
bzimport set Reference to bz49371.
bzimport added a subscriber: Unknown Object (MLST).

We are currently running it behind Apache as a reverse proxy. I'm fine with trying to improve caching here. If swapping Apache for $somethingElse is necessary, I'm fine with that too.

Change 75366 had a related patch set uploaded by Demon:
Allow the user's browser to cache resources

https://gerrit.wikimedia.org/r/75366

Change 75366 merged by Ryan Lane:
Allow the user's browser to cache resources

https://gerrit.wikimedia.org/r/75366

This is now deployed with a default expiry of 5 minutes. Look good to you Ori?

5 minutes seems too short -- it should be a week or more for some static assets -- and I don't think "Cache-Control: private, must-revalidate" is appropriate for an unauthenticated, read-only view of Git data.

5 minutes was mostly for testing. That being said, I think this setting affects too many things and not just resources. Maybe we need to hack it a bit.

demon claimed this task.