Include Cache-Control in API response

[triblondon]

Include Cache-Control in API response

[samgiles]

1 hour seems short for a service such as this. Polyfills are rarely going to change except perhaps after a deployment, is there any reason in particular for 1 hour?

[triblondon]

We might release a new polyfill or a bugfix for an existing one, and then
the TTL will determine how quickly it rolls out. I'd say it should be a
day at the most.

[commuterjoy]

This thread does raise the question of versioning (in the URL). You don't want to be waiting an hour (or a day) for anything critical to be pushed out.

[triblondon]

Well, as long as the service doesn't prohibit random query string arguments, versioning on the URL is out of scope here. A product can use them, or not, as it likes. There is obviously a big cache efficiency implication to advising all developers to add them though.

[samgiles]

We could add a Last-Modified header and a shorter TTL?

[triblondon]

Last mod doesn't help predict when it will next change. Let's go with a day, Matt and co can use query string versions, and if versioning causes cache degradation, we can address that.

[triblondon]

Last mod is also hard to compute because the output is a bundle. You'd have to take the most recently modified polyfill in the bundle. Not worth it.