Attempting to generate the following Cache-Control header Cache-Control: no-store, max-age=0 as illustrated here but unable to do so with org.springframework.http.CacheControl which is the required arg in org.springframework.web.servlet.mvc.WebContentInterceptor#addCacheMapping.
Would be nice to allow setters with a comment that suggests using builder functionality if unsure.
Comment From: bclozel
It think this combination of directives is really for client requests, not for server responses.
CacheControl can be used for both client and servers cases through the HttpHeaders and it looks like we might have missed this case. There is still a way to set this specific combination through HttpHeaders.setCacheControl(String), but not with WebContentInterceptor.
Could you check whether this scenario really applies to the server response use case?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: cwjenkins
Hey @bclozel, if I get time I'll dig through firefox/chrome source to see how those two implemented it. https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttp.cpp#349 https://github.com/chromium/chromium/blob/99314be8152e688bafbbf9a615536bdbb289ea87/net/http/http_response_headers.cc#L1013 The above snippets showcase how they force revalidation, but I need to track where cache pops occur.
I was just going by the MDN docs that explicitly state its for server responses. The way they explain it is no-store only pertains to the current request/response, but will not remove previous cached entries. In order to remove previous cached entries one must set the age to 0. I certainly don't see this called out in the RFC so maybe their docs are mistaken?
Comment From: bclozel
@cwjenkins this is sometimes hard to tell, even with RFCs and very good documentation.
Same as you, I'm not reading that in the spec - this might be something that browsers do still.
I can definitely understand a client asking for Cache-Control: no-store, max-age=0: don't cache my request (?) and don't give me a cached response.
I don't see why proxies would not wipe the corresponding cache entry if the servers starts replying with just "no-store".
We're trying to keep the CacheControl arrangement here straightforward for server developers, avoiding incompatible headers combinations (or unsupported, unrelevant headers). Depending on how relevant this case is, we might have to consider the tradeoffs. Right now providing this extra flexibility would make it easy for developers to end up with Cache-Control: no-store, max-age=3600.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.