Add browser support info for the HTTP Cache-Control header "immutable" flag #2828

Open
scunliffe opened this Issue Sep 22, 2016 · 12 comments

Comments

Projects
None yet
@scunliffe

Browsers that support the immutable flag on the HTTP Cache-Control header won't send useless (If-None-Match or If-Modified-Since) requests just to get 304s on static content.

This was just added to Firefox 49: https://developer.mozilla.org/en-US/Firefox/Releases/49
Details about why this is important: http://bitsup.blogspot.ca/2016/05/cache-control-immutable.html?m=1

@Schweinepriester

This comment has been minimized.

Show comment
Hide comment
Contributor

Schweinepriester commented Sep 22, 2016

@slorber

This comment has been minimized.

Show comment
Hide comment
@slorber

slorber Nov 8, 2016

+1 this is a really useful flag.

I have a S3 bucket with CloudFront on top of it, I never erase any file here and would like to serve immutable content to the user but don't know the support :(

slorber commented Nov 8, 2016

+1 this is a really useful flag.

I have a S3 bucket with CloudFront on top of it, I never erase any file here and would like to serve immutable content to the user but don't know the support :(

@temoto

This comment has been minimized.

Show comment
Hide comment
@temoto

temoto Jan 31, 2017

Chrome bug so far says "we don't force revalidation since 54 anyway, so this flag would have no effect". So that probably means that in caniuse, Chrome 54+ should display as something like "supports same behavior via different syntax".

temoto commented Jan 31, 2017

Chrome bug so far says "we don't force revalidation since 54 anyway, so this flag would have no effect". So that probably means that in caniuse, Chrome 54+ should display as something like "supports same behavior via different syntax".

@anthonyryan1

This comment has been minimized.

Show comment
Hide comment
@anthonyryan1

anthonyryan1 Jan 31, 2017

Contributor

I'd argue the opposite. I think that's Chrome saying they feel this feature is superfluous and they don't intend to implement it.

Contributor

anthonyryan1 commented Jan 31, 2017

I'd argue the opposite. I think that's Chrome saying they feel this feature is superfluous and they don't intend to implement it.

@scunliffe

This comment has been minimized.

Show comment
Hide comment
@scunliffe

scunliffe Jan 31, 2017

@temoto

This comment has been minimized.

Show comment
Hide comment
@temoto

temoto Jan 31, 2017

I hope we don't fall into useless chat here, but the immutabe syntax is in fact superflous. The behavior was already present with cache-control: public, max-age=large, but browsers interpreted it in "wrong" way, doing useless revalidation in presence of etag.

I hope we agree that behavior of avoiding excess validation is what's really important, developers need to know how to make their pages fast. And then they find advice to use this syntax for this browser, that syntax for that browser, as long as syntaxes don't conflict, add everything and be happy.

temoto commented Jan 31, 2017

I hope we don't fall into useless chat here, but the immutabe syntax is in fact superflous. The behavior was already present with cache-control: public, max-age=large, but browsers interpreted it in "wrong" way, doing useless revalidation in presence of etag.

I hope we agree that behavior of avoiding excess validation is what's really important, developers need to know how to make their pages fast. And then they find advice to use this syntax for this browser, that syntax for that browser, as long as syntaxes don't conflict, add everything and be happy.

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Feb 1, 2017

Contributor

WebKit has it too: https://bugs.webkit.org/show_bug.cgi?id=167497 And they’re now looking to implement Chrome’s behavior, where the HTTP header opt-in is not even needed anymore.

Contributor

mathiasbynens commented Feb 1, 2017

WebKit has it too: https://bugs.webkit.org/show_bug.cgi?id=167497 And they’re now looking to implement Chrome’s behavior, where the HTTP header opt-in is not even needed anymore.

@mkurz

This comment has been minimized.

Show comment
Hide comment
@mkurz

mkurz Apr 20, 2017

Contributor

Microsoft Edge 15 also shipped cache-control:immutable with the Creator Update! 🎉

They just updated the uservoice ticket:
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/17168363-support-chrome-s-improved-reload-behavior-or-cache

Contributor

mkurz commented Apr 20, 2017

Microsoft Edge 15 also shipped cache-control:immutable with the Creator Update! 🎉

They just updated the uservoice ticket:
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/17168363-support-chrome-s-improved-reload-behavior-or-cache

@mkurz

This comment has been minimized.

Show comment
Hide comment
@mkurz

mkurz Apr 20, 2017

Contributor

The Microsoft team also updated it's official status just now: MicrosoftEdge/Status#514 🎉

Contributor

mkurz commented Apr 20, 2017

The Microsoft team also updated it's official status just now: MicrosoftEdge/Status#514 🎉

@Calico90

This comment has been minimized.

Show comment
Hide comment
@Calico90

Calico90 Apr 20, 2017

Contributor

+1

Contributor

Calico90 commented Apr 20, 2017

+1

@Quezler

This comment has been minimized.

Show comment
Hide comment

Quezler commented Mar 20, 2018

+1

@Malvoz

This comment has been minimized.

Show comment
Hide comment
@Malvoz

Malvoz Apr 16, 2018

Contributor

+1

Contributor

Malvoz commented Apr 16, 2018

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment