I cannot get azure blob storage hosted fonts exposed via azure cdn working in IE or Firefox.
I believe this is because of #font-face cross-domain issues (CORS) and the normal solution is to add an Access-Control-Allow-Origin header. I know that most CDNs now support this but am assuming that Azure still doesn't. Can anyone confirm this?
If this is the case, are there any workarounds?
This is no longer true, azure supports CORS
http://blogs.msdn.com/b/windowsazurestorage/archive/2013/11/27/windows-azure-storage-release-introducing-cors-json-minute-metrics-and-more.aspx
and a little guide to adding fonts to your azure cdn:
http://www.devtrends.co.uk/blog/hosting-web-fonts-in-azure-blob-storage-using-the-new-cors-support
The CDN doesn't modify the headers from the origin, so it responds with whatever headers blob storage emits. Blob storage does not support CORS headers.
I'm surprised to learn that #font-face has cross-domain restrictions, but it appears that you're right (for Firefox and IE).
If you have that option, you could put the fonts on a cloud service (rather than blob storage) behind the CDN and emit the right headers there.
Your assessment is correct.
As a workaround, our company is utilizing Google storage (which supports CORS).
I would also suggest voting up this issue so the Azure team knows how many people are running into it.
http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/2850796-support-cross-origin-resource-sharing-cors-via-a
I can use fonts, without setting up the CORS option anyway. I'm linking my fonts directly to the blob storage, and not a CDN, since this one does not supports the CORS from the blob.
Related
Haven't found many resources for this - If I wanted to use jQuery in my app, for example, would it be more beneficial to download jQuery into my project's directory, or to link the google CDN for use?
CDN -
Less Latency
Using a CDN: Using a CDN helps bring resources closer to the user by
caching them in multiple locations around the world. Once those
resources are cached, a user’s request only needs to travel to the
closest Point of Presence to retrieve that data instead of going back
to the origin server each time.
Without CDN - Offline test localhost
You can test your website on your local machine without network
connectivity if you serve your libraries locally while in development.
Without CDN Monkey Patching
You can modify and fix certain issues in a library that create
breaking issues in your software and host these. If you use a CDN you
will have to use the original library's code instead thus losing these
fixes.
I have a tomcat web application that is using CloudFront, Apache, and S3 for static content delivery. The static content uses a versioned folder structure to allow for zero downtime upgrades:
V1
css
images
javascript
fonts
V2
css
images
javascript
fonts
etc
For everything but css files, these are referenced straight away to the CDN from the application. However, supporting the existing enterprise web application is necessary, so the existing /images and /fonts references cannot be changed.
To combat this, I've set up a custom origin on an apache EC2 that serves as a reverse proxy to the S3 bucket. It uses the referer header from the css file to direct the image reference to the correct directory.
This works fine, except for fonts where firefox reports that a CORS violation is occurring on the EC2. This doesn't make any sense to me since both the all of the content is hosted on the S3 itself.
Nonetheless, I have the CORS configuration set in the S3 bucket, a Header being set in apache for Access-Allow-Control-Origin, and CloudFront passing the Origin header. The css files are served fine with no CORS violations, but the fonts will not be served. Is there a configuration in Apache that I'm missing, or is it something else? I'd appreciate any help I can get.
Thanks
On June 26, 2014 AWS added support for CORS in CloudFront, are you using this support?
This SO answer provides info about enabling it for a particular distribution:
https://stackoverflow.com/a/24459590/3195497
If this is not enabled, then my guess is that CloudFront has cached a response without a Access-Allow-Control-Origin header and is serving that response regardless of what Origin is sent in the request.
I use both Telerik and Microsoft CDN, for their respective AJAX toolkits. Both work great 99% of the time. However, I was working out of two different cafes recently and went to visit my site: The first cafe did not permit the Telerik CDN, while the second one does not allow the Microsoft CDN as a URL request. I can actually see the status bar in IE shows "ajax.microsoft.com" as the file being retrieved as I am waiting for the website to load.
Lack of CDN access seems to be a very unusual problem. In fact, I cannot fathom why such URL requests would be blocked when the cafe seems to permit pretty much everything else. Any reason? Could this be an availability issue at the respective CDNs themselves (ie how reliable are these CDNs)? And of-course, is there a recommended fix, apart from discarding CDN use?
Update: I can now connect to my app. So my lack of access to ajax.microsoft.com was most likely a temporary lack of MS CDN availability, and not any domain blocking.
all you need to do is implement fallback to your local server, explained here, http://happyworm.com/blog/2010/01/28/a-simple-and-robust-cdn-failover-for-jquery-14-in-one-line/
The Telerik online demos use the CDN by default, but fallback to embedded resources if the Amazon cloud service is unavailable. If you have the RadControls for ASP.NET AJAX installed locally, then you can see the source of the demo site. The files that you need to review are ~/Common/Footer.ascx and its code file ~/App_Code/QuickStart/Footer.cs, also
~/App_Code/QuickStart/QsfCdnConfigurator.cs ~/App_Code/QuickStart/HeadTag.cs. The Footer files set a cookie using JavaScript, depending on whether the CDN is available and the last two files provide support for reading the cookie on the server side and setting the appropriate configuration for the script manager.
Dave Ward says,
It’s not exactly light reading, but section 4.2 of RFC 3986 provides for fully qualified URLs that omit protocol (the HTTP or HTTPS) altogether. When a URL’s protocol is omitted, the browser uses the underlying document’s protocol instead.
Put simply, these “protocol-less” URLs allow a reference like this to work in every browser you’ll try it in:
//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js
It looks strange at first, but this “protocol-less” URL is the best way to reference third party content that’s available via both HTTP and HTTPS.
This would certainly solve a bunch of mixed-content errors we're seeing on HTTP pages -- assuming that our assets are available via both HTTP and HTTPS.
Is this completely cross-browser compatible? Are there any other caveats?
I tested it thoroughly before publishing. Of all the browsers available to test against on Browsershots, I could only find one that did not handle the protocol relative URL correctly: an obscure *nix browser called Dillo.
There are two drawbacks I've received feedback about:
Protocol-less URLs may not work as expected when you "open" a local file in your browser, because the page's base protocol will be file:///. Especially when you're using the protocol-less URL for an external resource like a CDN-hosted asset. Using a local web server like Apache or IIS to test against http://localhost addresses works fine though.
Apparently there's at least one iPhone feed reader app that does not handle the protocol-less URLs correctly. I'm not aware of which one has the problem or how popular it is. For hosting a JavaScript file, that's not a big problem since RSS readers typically ignore JavaScript content anyway. However, it could be an issue if you're using these URLs for media like images inside content that needs to be syndicated via RSS (though, this single reader app on a single platform probably accounts for a very marginal number of readers).
The question of whether one could change all their links to be protocol-relative may be moot, considering the question of whether one should do so. According to Paul Irish:
2014.12.17: Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the
asset you need is available on SSL, then always use the https://
asset.
If you use protocol-less URLs to load stylesheets, IE 7 & 8 will download them twice:
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
So, this is to be avoided for CSS if you like good performance.
Yes, network-path references were already specified in RFC 1808 and should work with all browsers.
Is this completely cross-browser compatible? Are there any other caveats?
Just to throw this in the mix, if you are developing on a local server, it might not work. You need to specify a scheme, otherwise the browser may assume that src="//cdn.example.com/js_file.js" is src="file://cdn.example.com/js_file.js", which will break since you're not hosting this resource locally.
Microsoft Internet Explorer seem to be particularly sensitive to this, see this question: Not able to load jQuery in Internet Explorer on localhost (WAMP)
You would probably always try to find a solution that works on all your environments with the least amount of modifications needed.
The solution used by HTML5Boilerplate is to have a fallback when the resource is not loaded correctly, but that only works if you incorporate a check:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>
I posted this answer here as well.
UPDATE: HTML5Boilerplate now uses <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"> after deciding to deprecate protocol relative URLs, see here.
If you would like to make sure all requests are upgraded to secure protocol then there is simple option to use Content Security Policy header upgrade-insecure-requests
Content-Security-Policy: upgrade-insecure-requests;
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests
I have not had these issues when using ://example.com - but you do need to add the colon at the beginning. Yoast had a good write up about this a while back. But it's lost in his pile of blog posts.
I'm using TypeKit to provide fonts for a site I'm developing. When the page is loading it loads slow (more than a second). Turns out that this is because it's downloading the fonts on every requests. It's beyond me that a service such as this doesn't have etags configured to get clients to cache the fonts...but I digress. Until TypeKit fixes this I host the CSS locally temporarily.
Anyone had this issue with TypeKit? How did you work around it? Perhaps I'm wrong?
According to a posting on their getsatisfaction.com account, they have at least some caching in place:
One thing to note is that although the fonts are served with an Expires header, they're also served with an Etag. The browser is required to make a request after 5 minutes, but will normally use the Etag to generate a 304 (Not Modified) response - meaning, the fonts aren't actually downloaded again.
can you check what happens using Firebug?