Closed Bug 1285969 Opened 4 years ago Closed 4 years ago

add cache control header to balrog


(Release Engineering Graveyard :: Applications: Balrog (backend), defect)

Not set


(Not tracked)



(Reporter: bhearsum, Assigned: bhearsum)




(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)
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)
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.
Details in the PR, as usual.
Attachment #8770587 - Flags: review?(rail)
Attachment #8770587 - Flags: review?(bwong)
Attachment #8770587 - Flags: review?(rail) → review+
Attachment #8770587 - Flags: review?(bwong)
Commit pushed to master at
bug 1285969: Set cache control header for public app (#98). r=rail,mostlygeek
Depends on: 1287494
This is working fine in production.
Closed: 4 years ago
Resolution: --- → FIXED
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.