Safari does not cache resources in different domains

Let's say we have several different sites: website1.com, website2.com, website3.com. We use jQuery for all of them and include it from the CDN, for example googleapis.com. The expected behavior of the browser would be to cache it once and use it for all other websites. Chrome seems to do this, but Safari loads jQuery for each domain.

Example

  • With the given JS code below nytimes.com , bbc.com and dw.de in Chrome.
  • Add jQuery to your first website and see the Network tab of your DevTools. He will say that he got jQuery.
  • Now open any other site and add jQuery again - the answer will be "from the cache."

However, Safari will say jQuery loading for each domain, but try to open any web page in one of the domains and add the script again - you will see that now it says that it got jQuery from the cache. Thus, it looks like it is caching data for the domain, even if it already downloaded the resource from the exact URL for another domain.

Is this assumption correct, and if so, how to fix it?

Code you can copy / paste:

setTimeout(function() { var SCRIPT_SRC = '//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js'; var s = document.createElement('script'); s.type = 'text/javascript'; s.async = true; s.src = SCRIPT_SRC; var x = document.getElementsByTagName('script')[0]; x.parentNode.insertBefore(s, x); }, 0); 

UPD: Tested with a static image.

test.com, test2.com and test3.com have <img src="http://image.com/image.jpg" /> . In all browsers except the Safari access log, only one is displayed - the first request for an image. Safari receives an image for each new domain (but not a subdomain).

+7
safari caching browser-cache cdn google-cdn
source share
3 answers

Instead of just adding a DOM element, you can try using XMLHTTPRequest. It allows you to define custom headers - one of which is Cache-Control .

Give this snapshot, it should redefine everything that happens at the browser level:

 (function () { var newRequest = function() { return (window.XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject( 'MsXml2.XmlHttp' ); } var loadScript = function(url) { var http = new newRequest(); http.onReadyStateChange = function() { if (http.readyState === 4) { if (http.status === 200 || http.status === 304) { appendToPage(http.responseText); } } } // This is where you set your cache http.setRequestHeader( 'Cache-Control', 'max-age=0' )// <-- change this to a value larger than 0 http.open('GET', url, true); http.send(null); } var appendToPage = function(source) { if (source === null) return false; var head = document.getElementsByTagName('head')[0]; var script = document.createElement('script'); script.language = 'javascript'; script.type = 'text/javascript'; script.defer = true; script.text = source; head.appendChild(script); } loadScript( '//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js' ); })(); 

Note. Safari had some caching problems in the past. However, from what I understand, it's mostly about serving outdated content, not the other way around.

0
source share

I also noticed this, and I suspect that this is due to privacy.

By default, Safari blocks third-party cookies . The third cookie is a cookie located on b.com for the resource requested by a.com . This can be used, for example, to track people by domain. You can have a script on b.com that is requested by c.com and c.com . b.com can insert a unique customer ID into this script based on a third-party cookie so that c.com and c.com can track that it is the same person.

Safari blocks this behavior. If b.com sets a cookie for the resource requested by a.com , Safari will insert this cookie, so it is only sent to b.com to receive additional b.com requests. It will not be sent to b.com for c.com requests.

Now enter the caching and specifically the Etag header. Etag is an arbitrary string (usually a file hash) that can be used to determine if the requested resource has changed since the last user requested it. This is usually good. It saves re-sending the entire file if it has not changed.

However, since Etag is an arbitrary string, b.com can set a client identifier for it. This is called Etag Tracking . This allows you to track a user across domains in much the same way as cookies.


Summary. . By not sharing the cache in the domains, Safari protects you from cross-domain Etag tracking.

0
source share

Here are some suggestions:

  • Have you checked if the "disable cache" option is disabled?
  • Are you looking for the HTTP status code in the Network Developer Panel?
  • Have you tried to capture traffic with tools like WireShark ?

Sincerely.

-one
source share

All Articles