Still need cache-busting on CSS file? #27657
-
|
I read this but still am having trouble: According to that issue and @SteveSandersonMS , I don't need cache-busting URLs, as Blazor will automatically request a fresh one as needed. Yet when I deploy my site and open it in Firefox, I get the old styles and see in Firefox developer tools network tab that app.min.css is retrieved from disk cache. I have to press Ctrl+F5 to get the new styles. So what is going wrong in this chain? It seems to me that I still need cache-busting URL for my CSS on each deployment. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 11 replies
-
|
Cross-posted here: https://stackoverflow.com/questions/64760377/still-need-cache-busting-on-css-file-in-blazor-webassembly-site |
Beta Was this translation helpful? Give feedback.
-
|
Whether or not the browser uses cached copies is controlled by the HTTP headers sent by your server when it returned the |
Beta Was this translation helpful? Give feedback.
-
|
OK, so I went back to the simple approach you suggest: simply Thus, when I deploy a new version of the CSS, users get display bugs shown on their page. This seems to be in contradiction to the MDN page you cite above, which says:
Yet that doesn't always happen. I'll post some screenshots... I also see this comment from you... curious, has your position changed? Because I believe I'm looking for exactly what you suggest:
|
Beta Was this translation helpful? Give feedback.
-
|
Here are two consecutive requests, once pressing F5 gave me an unexpected no-request-at-all reresh, and then another simple F5 refresh then gave me the expected CSS request with the expected 304. In the first case, the user could get an improperly-styled page. Are you sure there's nothing in Blazor that could be suppressing certain requests? When I hit F5, does Blazor somehow avoid making a completely new request, or something like that?
|
Beta Was this translation helpful? Give feedback.
-
|
My comment was about the framework resources that Blazor itself controls the responses for. For those, the framework chooses and knows about the desired refresh semantics. Since I posted that, we've implemented logic within For other resources that Blazor doesn't control, such as your CSS files, it's entirely up to you to choose the desired caching semantics and to control that via HTTP headers or any custom logic you want around loading them. In the vast majority of cases developers don't need to take any steps, because ASP.NET Core's built-in default static files middleware produces |
Beta Was this translation helpful? Give feedback.
-
|
OK, thanks for all the explanation. I agree--that all makes sense and should be correct. The Firefox behavior seems odd to me, so I am asking about that here. |
Beta Was this translation helpful? Give feedback.
-
|
I now suspect my problem might actually be a bug or design issue in Firefox; we'll see if we can pursue it further there. |
Beta Was this translation helpful? Give feedback.
-
No, Blazor is not involved in serving the static content (CSS files in |
Beta Was this translation helpful? Give feedback.
Whether or not the browser uses cached copies is controlled by the HTTP headers sent by your server when it returned the
.cssfile previously. As long as it has a validetagthen the browser should check for updates via a request withan If-Modified-Sinceheader. This isn't something that Blazor WebAssembly controls, since Blazor WebAssembly is purely client-side and hence doesn't control the headers sent by your server.