4 ms·

I still sometimes see "broken" pages (on both desktop and mobile - more common with flaky WiFi) - e.g. pages that have bad or broken CSS because the server conn

I still sometimes see "broken" pages (on both desktop and mobile - more common with flaky WiFi) - e.g. pages that have bad or broken CSS because the server connection was interrupted. The resulting pages are usually nigh-unusable, and the broken resources can end up cached in the browser. Usually a reload will solve this issue. It sounds like the Chrome team wanted to validate only the main resource and rely on cached data - isn't this inherently going to break the "reload a broken page" use case? It sounds as if the Chrome team wants to abandon that use case entirely because "the quality of webpages has improved". That may be true - but the quality of some network links hasn't!

adrianN 10y ago
When things don't work as expected I usually do a skip-the-cache reload (cmd-shift-r, ctrl-shift-r).
benmaurer 10y ago
This use case will still work. If your connection is interrupted the resource will not be cached. The new reload behavior will still cause the resource to be re-requested. What if the resource is corrupt -- say a bit got flipped due to a hardware error. In the old version of reload you would send a conditional request to the server "has this resource been modified since date X". The server would say "no it hasn't" with a 304 (unless the bit flip happened to affect the header and changed the date to a much newer date). Thus a normal reload would cause you to continue to use the invalid resource. The only way to fix this situation is by doing a ctrl+shift+r -- neither Chrome's nor Firefox's approach makes this worse than it was in the past
- benjaminjackman 10y ago
  That is pretty good explantion. It seems like it's possible to kill two birds (avoiding unneeded 304s and correcting corruption) with one stone and solve this problem via something like pushing subresource integrity [1] ahead, as well as a magnet uri / IPFS notion of linking to content by it's hash. 1: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

adrianN 10y ago

When things don't work as expected I usually do a skip-the-cache reload (cmd-shift-r, ctrl-shift-r).

benmaurer 10y ago

This use case will still work. If your connection is interrupted the resource will not be cached. The new reload behavior will still cause the resource to be re-requested. What if the resource is corrupt -- say a bit got flipped due to a hardware error. In the old version of reload you would send a conditional request to the server "has this resource been modified since date X". The server would say "no it hasn't" with a 304 (unless the bit flip happened to affect the header and changed the date to a much newer date). Thus a normal reload would cause you to continue to use the invalid resource. The only way to fix this situation is by doing a ctrl+shift+r -- neither Chrome's nor Firefox's approach makes this worse than it was in the past

benjaminjackman 10y ago
That is pretty good explantion. It seems like it's possible to kill two birds (avoiding unneeded 304s and correcting corruption) with one stone and solve this problem via something like pushing subresource integrity [1] ahead, as well as a magnet uri / IPFS notion of linking to content by it's hash. 1: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...