1285969 - add cache control header to balrog

Status: RESOLVED FIXED

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

Description

[[e-mail] (:bhearsum)]

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?

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

I don't remember any more than that but it does go back a very long way, possibly to Firefox 1.5 days.

Comment 2

[Robert Strong (they/them - no direct email)]

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.

Comment 3

[[e-mail] (:bhearsum)]

Attachment: add cache control header to non-error responses

Details in the PR, as usual.

Comment 4

[[github robot]]

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

Comment 5

[[e-mail] (:bhearsum)]

This is working fine in production.