I've read that Firefox has begun supporting a cache control extension value of immutable, which means that "the response body will not change over time." So even if a user requests a "full refresh" of a page or resource, the browser still only responds with the locally cached copy, thus avoiding unnecessary 304s or page refreshes, and making pages load faster since cached content is used, and decreasing load on servers, since a large number of requests are stopped before they even happen.
I'm trying to see how well this is supported, and am finding varying answers, as this mozilla page suggests that it's only supported in Firefox, but this resolved Chrome issue suggests it's been available since Chrome v54.
Which browsers support Cache-Control: immutable, and when did they start supporting it?
I first read about it here on this Hacker News discussion
Here's an ietf draft on it, the original mozilla post announcing this beta feature being used by Facebook and this related mozilla post, and a document discussing the different types of reloading requests from some Google chrome devs, it appears.
As of February 2017, Cache-Control: immutable is supported by
Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1267474) since Firefox 49
Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=611416) since Chrome 54 They aren't implementing this.
Safari (https://bugs.webkit.org/show_bug.cgi?id=167497) in Safari Technology Preview 24.
It is also listed on MDN and Can I Use ... ?.
As of April 2017 it is also supported in "classic" Edge
Related
CanIUse and MDN doesn;t seems to be agree on the support for service worker. In the midst of Chrome going to remove support for appcach, we are trying to ascertain the impact of moving to Service Worker. Are we reading the above two pages incorrectly?
We tried Google's own samples against device/browser combinations and results wore not encouraging. For example the 'custom offline page' demo failed in iOS Chrome (v80) where it worked in iOS Safari (12.4.5).
The 'Selective caching' and 'Read through caching' pages clearly show "service worker is not supported in the current browser" in Chrome 80. It is checking the if ('serviceWorker' in navigator) {, but other samples doesn't show such a message.
All and all it is confusing on the browser support for the Service worker. Is there there a universally tested sample which we can use as a benchmark for different device/browser combination.
I asked Jake Archibald of Google on this and he replied with the following SO post which must be still valid.
Chrome Service Worker iOS Support
Therefore apparently Safari is the only option at the moment. I am still wondering what Google is recommending developers to use once they remove support for AppCache.
Jake continued saying there is no way they can add support as Apple is not giving them full rights on iOS. But he mentioned appcache will continue to work as usual. His exact words are
"However, since Chrome on iOS is just a skin over Safari, appcache will continue to work while it works in Safari webview."
on iOS only Safari supports service workers. You can test browsers if it supports with this code
if ('serviceWorker' in navigator) { /*supported*/ }
This is probably a silly question, however: from a Web Design/Development point of view (I mean support for web standards and web technologies), could Google Chrome and Chromium be considered equivalent?
I know that they are essentially the same browser, the former being the branded version of the latter, but they also have some functional differences, and Google Chrome features some additions not present in the base Chromium browser (detailed on the Chromium page on Wikipedia).
They use the Blink engine, which is in turn also used by other Chromium-based browsers like MS Edge and Opera; and all these browsers have an uneven support for many different web technologies, as detailed on https://caniuse.com.
I'm working on a Linux machine, and my distro ships Chromium by default, providing it from its standard repo; for the sake of simplicity and keeping things clean, I would prefer to avoid adding another external repo and install Chrome just for this task, if I can rely Chromium to behave exactly the same and not have any compatibility issue.
Like I said, this question is probably silly, but given the differences between other Chromium-based browsers, maybe this doubt of mine could be justified.
EDIT: Please note that I'm not interested in the differences between Google Chrome and Chromium from an user point of view or in details of their history and so on; I only wish to know if from a website development point of view, they are fully compatible or if they support the same set of features. In other words, if I test a site from Chromium, can I be sure that it will work also in Google Chrome? Do they support the same exact set of CSS, JS (and other web-related technologies) features?
Chromium is an open-source browser project that forms the basis for the Chrome web browser. It's maintained by the Chromium Project, while Chrome is maintained by Google. Aside from code-opennes, the main difference (for your concerning question) between the two browsers is that Google adds a number of proprietary features to Chrome like automatic updates and support for additional video formats. Also added is AAC, H.264, and MP3 support. Giving you acess to a wider variety of media content, like sites using HTML5 to stream H.264 videos. Both browsers include Opus, Theora, Vorbis, VP8, VP9, and WAV codecs. Chrome also includes a sandboxed Adobe Pepper API (PPAPI) Flash plug-in that updates along with.
From a programmatic side, both support Google DevTools protocol with all of the flexibility and possibilities this brings, like browser automation using the popular puppeteer Node.js runtime, allowing you to run automated tests either in head or headless environments. Both browsers use the Blink rendering engine and the V8 JavaScript engine, so both will give you same support for CSS, HTML and DOM parsing/rendering, and same JavaScript compatibility, functionality and performance. So the real difference is if you're developing media-content centric web apps, in that case you will benefit more from Chrome since it includes all of the above mentioned extra plugins and supported formats, all of this makes the web more accessible to it and provides a wider range of things you could do.
I've been reading various informations about Google and Firefox using an HSTS preload list.
it seems that there is a generic list here : https://hstspreload.org/
and that Chrome uses the one from Chromium here :
https://www.chromium.org/hsts/
and Firefox uses the one here :
https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc
Does Safari or Opera use a HSTS preload list ? Which one ? What is the relationship between the 3 list cited above ?
Thank you
The defacto central master list for HSTS is managed by Chromium / Google
at https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json .
A list of Browsers supporting HSTS (and presumably having preload lists) can be found at Wikipedia.
Being closed source, information on how Opera, Safari, IE, etc. handle their preloaded lists seem to be unavailable.
The Microsoft Edge Team state in their Blog, that
Like other browsers which have implemented this feature, Microsoft Edge and Internet Explorer 11 base their preload list on the Chromium HSTS preload list.
For Firefox, the list at /source/mozilla/security/manager/ssl/nsSTSPreloadList.inc is generated by the file
/source/mozilla/security/manager/tools/getHSTSPreloadList.js, where we can see from the line
const SOURCE = "https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json?format=TEXT";
that it is merely a clone of the "master list", parsed into Firefox` format.
All it does is an additional verification run for each domain in the list to be available and have the required HSTS header (by connecting to it; which it seems to do daily, from the vcs log).
Palemoon follows this procedure and it is likely that other browser vendors do the same.
So it seems the relationship between your lists is: there is only one.
From your first link:
Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge)
also have HSTS preload lists based on the Chrome list. (See the HSTS
compatibility matrix.)
We recently discovered an interesting bug in newly released Chrome v.39.
It just crashed with standard "Aw Snap!" message on every page with an iframe if that iframe loads a page with Content-Security-Policy HTTP header. This blocked out web-site because we host some third-party ads.
From what i found the "Content-Security-Policy" header is a W3C standard and Google Chrome used to support in between v.25 and v.38 releases. But from now they don't.
Does anyone know a nice practical solution for this issue? Is there a way to prevent Chrome from crashing without this workaround?
If you want support Chrome 39/40, I found that adding the protocol in front of domain would prevent the crash (It's not required in CSP 2.0, but it's better than crash).
If you want support Chrome 41, it didn't crash even without protocol name.
Hope this helps.
In order to fix the issue we had to add a logic that sends X-Content-Security-Policy to all but IE and Content-Security-Policy to IE only. This is ugly code/solution but at least it stopped crashing.
From the documentation of $location
Fallback for legacy browsers For browsers that support the HTML5
history API, $location uses the HTML5 history API to write path and
search. If the history API is not supported by a browser, $location
supplies a Hasbang URL. This frees you from having to worry about
whether the browser viewing your app supports the history API or not;
the $location service makes this transparent to you.
It works fine under FF,Chrome and IE10 (whatever the browser mode). However when I try to test in less than IE9 mode, the fallback mode with hashbang behaves oddly. The window location is converted as expected
http://myserver.net/#!/thewebapp
it displays the server root content since angularjs fails during the rendering.
SCRIPT5022: 10 $digest() iterations reached. Aborting!
After reading other Q/A, I suspect IE10 can't be used this way. Another source is maybe the server side rewriting or a combination of both. Right now I have no clue.