-
-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Cache-Control: immutable #140
Conversation
So after some (light) reading, I realize (and I don't think I did before) that "immutable" is actually useful for any cache duration, so saying max age 4 hours + immutable is a valid configuration. I am going to land this still, still with full credit to @jcready , but with the following API change: instead of |
Another option, just to throw it out there (though it's high visibility), is to actually deprecate the I'm not 100% sure how I feel about deprecating the |
Now I’m curious, how is “immutable” useful for any cache duration? Could you point me to what you were reading? |
I was specifically reading through the Firefox bug for the implementation https://bugzilla.mozilla.org/show_bug.cgi?id=1267474 and MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control Basically, it is a directive that tells the web browser that, if the browser has a valid cached version (which means it needs to have some directive to tell it to cache the response), it will just not send the revalidation requests until the resource expires out of the browser's cache. |
Interesting. I had (I guess incorrectly) assumed that “immutable” meant the resource could never change and that the maxAge part of it was only a fallback for clients that didn’t support the immutable part of the directive. |
Yea, I had the same assumption as well. |
If the
maxAge
option is set toInfinity
then the resulting header will be set:Resolves expressjs/express#3197