Add configuration option for cache-control: immutable in http header

[xguo27]

We are facing an issue where even we set all appropriate options delineated at: https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html the caching still does not work completely on Firefox. The goal is to have static files cached on local browser for users, with no re-fetching if the cache has not expired. Whereas what we see is that the cache gets invalidated every other time (caches only half of the time, and the response code flip-flops between 200 and 304). Turns out that firefox relies on cache-control: immutable to make sure the cache does not get invalidated.

Looking at https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/http/CacheControl.html , there is no option to set that immutable flag, is it possible to add the option?

[philwebb]

@xguo27 CacheControl is part of the Spring Framework so I've move your issue to their tracker (SPR-17013). You can watch that issue for updates.

[bclozel]

@xguo27 While adding immutable support in Spring Framework is a nice idea, you should still be able to get a decent HTTP caching configuration without it. I guess your static resources are not served with Last-Modified or ETag response headers and that explain the current behavior.

Did you take a look at the static resource chain?
Properties like those should help (and check out this workshop as well):

spring.resources.chain.enabled=true
spring.resources.chain.strategy.content.enabled=true

[xguo27]

Thanks @bclozel , we did set ETag while debugging this issue with no luck. I also tried spring.resources.chain.enabled=true
spring.resources.chain.strategy.content.enabled=true
that you suggested, unfortunately that does not work either. One of our team members tracked down a post https://code.fb.com/web/this-browser-tweak-saved-60-of-requests-to-facebook/ which lead us to believe only immutable tag works in this case.

FWIW, here is the response headers for one static resource we consistently get from Chrome, which caches just fine:

Cache-Control: max-age=31536000
Content-Encoding: gzip
Content-Type: application/javascript
Date: Fri, 06 Jul 2018 16:20:47 GMT
ETag: "0fbca1516a62036ef8722dbdccad8484c"
Expires: 
Last-Modified: Fri, 06 Jul 2018 15:44:08 GMT
Pragma: 
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Here is the two response headers we get alternatingly from Firefox:
when read from server

Accept-Ranges: bytes
Cache-Control: max-age=31536000
Content-Encoding: gzip
Content-Type: text/css
Date: Fri, 06 Jul 2018 16:15:21 GMT
ETag: "064dfb75ef30cbf691e7858dc1992b4df"
Expires: 
Last-Modified: Fri, 06 Jul 2018 15:44:08 GMT
Pragma: 
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

when read from cache

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Date: Fri, 06 Jul 2018 16:26:05 GMT
Expires: 0
Last-Modified: Fri, 06 Jul 2018 15:44:08 GMT
Pragma: no-cache
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

[bclozel]

@xguo27 This doesn't really tell me what's happening.
To figure things out, I'd need to see request/response pairs and even better, a sample application that demonstrates the issue.
I don't understand what "when read from cache" means - usually browsers don't show HTTP responses in their developer tools when resources are loaded from their cache.

This also might be Spring Security overwriting those caching headers (it depends on your security configuration and on your Spring Security version, since a possibly related issue was fixed in spring-projects/spring-security#5004).

[xguo27]

@bclozel Let me elaborate on the flow and what we see. When we first load the page on Firefox, we sent a request with header:

Accept: text/css,*/*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Cache-Control: max-age=0
Connection: keep-alive
Cookie: **some cookie** 
Host: **our web app server**
Referer: **the link we clicked on**
User-Agent: Mozilla/5.0 (Macintosh; Intel ...) Gecko/20100101 Firefox/61.0

which will load the static resource with status 200 and a response header:

Accept-Ranges: bytes
Cache-Control: max-age=31536000
Content-Encoding: gzip
Content-Type: text/css
Date: Fri, 06 Jul 2018 21:59:25 GMT
ETag: "064dfb75ef30cbf691e7858dc1992b4df"
Expires: 
Last-Modified: Sun, 01 Jul 2018 20:36:59 GMT
Pragma: 
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Now if we hit refresh button on the browser, the request is sent with header:

Accept: text/css,*/*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Cache-Control: max-age=0
Connection: keep-alive
Cookie: **some cookie** 
Host: **our web app server**
If-Modified-Since: Sun, 01 Jul 2018 20:36:59 GMT
Referer: **the link we clicked on**
User-Agent: Mozilla/5.0 (Macintosh; Intel ...) Gecko/20100101 Firefox/61.0

and we get a response with status 304, which indicates it's loaded from cache, and the response header is:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Date: Fri, 06 Jul 2018 22:06:57 GMT
Expires: 0
Last-Modified: Sun, 01 Jul 2018 20:36:59 GMT
Pragma: no-cache
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Now if we hit refresh button again, instead of a response of 304 for the same static resource, we get response 200 and a header just like the first one, as if it's a first load. And all subsequent refreshes will just toggle between these two responses between 200 and 304.

Firefox seems to be invalidating its cache after it's been served once, and I don't see same behavior on Chrome/Safari. Thus the request on adding immutable based on this post: https://code.fb.com/web/this-browser-tweak-saved-60-of-requests-to-facebook/

We filed a bug with Firefox and they chose not to alter the long standing behavior of the reload button. Instead, Firefox implemented a proposal from one of our engineers to add a new cache-control header for some resources in order to tell the browser that this resource should never be revalidated. The idea behind this header is that it’s an extra promise from the developer to the browser that this resource will never change during its max-age lifetime. Firefox chose to implement this directive in the form of a cache-control: immutable header.

There is a bit more developer overhead for Firefox’s change, but after we modified our servers to add the immutable header we began to see some great results.

[philwebb]

We filed a bug with Firefox and they chose not to alter the long standing behavior of the reload button

@xguo27 Can you provide a link to the reported issue please.

[xguo27]

@philwebb , I believe this is the bug facebook folks filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1267474

[bclozel]

@xguo27 looking at what you provided, I can only say Spring Boot is behaving as expected.
When you refresh the page, the browser is sending a Cache-Control: max-age=0 request header, which means the browser wants a fresh resource no matter what.

Now several things to consider:

• Your server is sending empty pragma and expires headers; it shouldn’t.
• your server is sending both etag and last modified headers. Etag alone should be fine.
• your browser is always sending a Cache-Control: max-age=0 header. Did you forget to uncheck the option disabling the cache when Firefox developer tools are opened?

In any case this not a Spring Boot bug, so we should continue this discussion on gitter or on stackoverflow.