Closed
Bug 1285969
Opened 9 years ago
Closed 9 years ago
add cache control header to balrog
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), defect)
Release Engineering Graveyard
Applications: Balrog (backend)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bhearsum)
References
Details
Attachments
(1 file)
As part of the transition to CloudOps we're going to start setting the Cache-Control header within the Balrog app (previously, it's been set by Zeus). Right now, the the WebOps hosted cluster sends:
Cache-Control: no-store, must-revalidate, post-check=0, pre-check=0, private
And as best as I can tell, the CloudOps hosted one sends no Cache-Control header at all at the moment. Benson has recommend that we set to a 60s cache.
I can't find anything solid about why we set it to 0 in the first place, but my brain seems to think that we were worried about proxies caching things for longer than we'd like. However, if we're only worried about proxies that don't respect what we set, it seems like it shouldn't matter if we set it to 0 or 60.
Robert or Nick, do either of you have any additional background on this?
Flags: needinfo?(nthomas)
Comment 1•9 years ago
|
||
I don't remember any more than that but it does go back a very long way, possibly to Firefox 1.5 days.
Flags: needinfo?(nthomas)
![]() |
||
Comment 2•9 years ago
|
||
Firefox 1.5 is years before I ever looked at the app update code and I have no idea about the reasoning for the aus changes though what you stated makes sense.
Assignee | ||
Comment 3•9 years ago
|
||
Details in the PR, as usual.
Attachment #8770587 -
Flags: review?(rail)
Attachment #8770587 -
Flags: review?(bwong)
Updated•9 years ago
|
Attachment #8770587 -
Flags: review?(rail) → review+
Updated•9 years ago
|
Attachment #8770587 -
Flags: review?(bwong)
Comment 4•9 years ago
|
||
Commit pushed to master at https://github.com/mozilla/balrog
https://github.com/mozilla/balrog/commit/2bd805aafde2d312a006729e11c38e268f088c65
bug 1285969: Set cache control header for public app (#98). r=rail,mostlygeek
Assignee | ||
Comment 5•9 years ago
|
||
This is working fine in production.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•