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.
Related
I have enabled HTTPS for my site. Some of the resources such as css and js files on my pages come from another domain which is on HTTP. Now the problem is when I visit the page, browsers display an alert message. IE says "Do you want to view only the page content that was delivered securely" and FF says "You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party."
I tried the technique mentioned by Paul Irish which is not working.
Any idea how I can resolve this issue?
I use asp.net 3.5 for my site.
The assumption he makes in the referenced article I think you missed is
… assuming the site you're pointing to has this asset available on
both HTTP and HTTPS.
Those resources need to be served over HTTPS as well, or you will always get that message. I don't believe there is a way around it, and there likely shouldn't be a way around it. You want everything running over HTTPS for a reason.
You need to serve those resources over HTTPS.
The Firefox Mixed Content Blocking Announcement does a good job explaining the security risks.
If you own/control the other website where the resource files are located, a good solution might be to move the resource files over to the website where both HTTP and HTTPS are supported, and change both websites to point to those files at their new location.
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.
I have a browser compatibilty problem with https? I have SSL installed and is in usage. Until today morning, my https part is working well. From then, Https is shown as https(with slashed in red color) saying the page has some insecure content.
I have not changed any code and suddenly i see this problem in chrome. In IE 8, i see the same problem but on every page, it shows me a popup if i should allow to opne secure and non secure or just secure. Firefox has no issues . It shows correct https without any problem. I am fed up with it searching all over. Why is this happenening for me in Chrome and IE 8.
Could someone tell me what the problem is and what can be done to solve it!
PS: I have also checked if the page source is any different when IE8 showed with and without secure data. Everything is the same. but viewstateID was different. Is that something that is creating this problem?
Thanks a lot in advance.
This is usually caused by having the absolute path to a resource specified somewhere on the page without having https specified, eg:
<img src="http://someurl.com/image.png">
If it's a link to something on your site, use https: or a relative path.
DO you have any 3:rd party javascript included, like google analytics or other that might have changed.
If you try with Firefox there is firebug you can add as an addon.
In there is a tab for network (net).
It lists everything the page loads.
In that list you should be able to find anything that gets loaded without https.
IE (correctly) complains when there is mixed http/https content as a security warning. Most other browsers do not typically complain when dealing with mixed content so your source is very likely the same in both instances.
I would second David Mårtensson's answer and say the issue is likely a third party library (google or MS hosted JQuery for example) or static asset server.
I posted a question the other day about why IE8 would not allow me to embed a page using the OBJECT tag. Per that discussion, and per my other research, I decided to just go with an IFRAME as it was not clear that the third-party application actually needed to be in an OBJECT.
Now here I am, a day later, finding out that IE8 has the same cross domain issue with IFRAME that it does with OBJECT. Is there any way around this? Why can I not find any discussion about this being an issue?
It has been awhile since I have had ot use an IFRAME for anything but I am pretty certain that this used to be really easy to do. Am I missing something, or am I really stuck going back to early AJAX days of having to build a local PHP proxy script to proxy my request to the remote server?
Take a look at EasyXDM. It's a library which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser. Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them).
I have a web page containing am entry form. HTTPS is enabled via an Apache redirect for all requests matching that page. Unfortunately, because the CSS pulls in external images using 'background-image: url(/images/...)', the browser will generate a warning message that the page contains mixed content.
What's the best way to resolve this issue?
Update 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.
Allowing the snippet to request over HTTP opens the door for attacks
like the recent Github Man-on-the-side attack. It’s always safe to
request HTTPS assets even if your site is on HTTP, however the reverse
is not true.
More guidance and details in Eric Mills’ guide to CDNs & HTTPS.
Source: Paul Irish – The Protocol-relative URL
Here is a very popular solution:
There's this little trick you can get away with that'll save you some headaches:
In HTML
<img src="//domain.com/img/logo.png">
In CSS
div{background: url(//path/to/image.png);}
You should also enable HTTPS for your static resources, and then make sure that the <link> refers explicitly to the HTTPS url for the CSS resource (whose relative urls will then be interpreted relative to the HTTPS base of the CSS file).
You should use full URL for your image:
https://your.domain.com/img/image.png`
or
https://your.domain.com/route/to/img/image.png
This solved my problem some time ago.