Can I change all my http:// links to just //?

Question

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?

Arborvitae

I readed about this technique at IE blog a while ago. But when I tried it din't work quite well. If my site was served with HTTPS, the browser (Chrome) was still using HTTP for protocol-less URLs. – Redolent

WARNING: remember to NEVER user schemeless URIs in HTTP 3xx redirects!! HTTP headers are not compatible with this URL format. If you need to redirect depending on scheme, use mod_rewrite or similar. – Orthotropous

@Orthotropous Experimentation in modern versions of Chrome and Firefox disagrees with you, as does the (still in draft) revision to the HTTP 1.1. spec defined by the HTTPbis working group (see svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Perhaps what you say is true of some browsers, though; do you know of any in particular that fail on protocol-relative URLs in location headers? – Prizefight

Same question with some good answers: Absolute URLs omitting the protocol (scheme) in order to preserve the one of the current page – Adonis

Don't use them, they are ugly and redundant. – Lues

Possible duplicate of Is it valid to replace http:// with // in a <script src="http://...">? – Rosenblatt

Answer 1

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:

1. 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.
2. 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).

Thalia

While IE7/8 handles protocol-relative URLs (aka. schemeless URIs) well in most cases, when stylesheets are specified with such URLs, it will download them twice. (So says Steve Souders) – Bloomfield

I'm finding that IE6 attempts to convert the URI to a relative one (i.e. removing one of the leading slashes). This is in a link element. For example, when specifying //fonts.googleapis.com/css?family=Rokkitt:400,700, IE6 tries to load http://mysite.com/fonts.googleapis.com/css/<...>. Not so good! – Manara

I've found from my logs instances of what seem to be web spider robots (source unknown) trying to use the protocol-less links and not handling them correctly as well. – Doralynn

I've seen a lot of that in my logs, unrelated to protocol-less URLs. A lot of those spiders are just incredibly poorly written. – Thalia

@CBono: //fonts.googleapis.com/family=... seems to work fine on IE6. Can you elaborate how to reproduce the problem? Does any one else have problems with IE6 and protocol relative URLs? – Wieren

@Manara is this still a problem for IE6? I have no way to test. – Drumm

@Drumm Yes, I recently attempted to convert a page over to use protocol-less URLs and had pretty bad results. – Manara

@JanM I have seen occasions where IE6 doesn't misinterpret these links, but more often than not it does. So there's some conditions, that I don't understand, that affect the behavior. Overall, it seems pretty delicate and I wouldn't trust IE6 to load these URLs correctly. – Manara

@Manara if //file doesn't work, would /file work for all browsers? – Drumm

@Drumm No, because then ALL browsers would interpret that as a relative link, rather than an absolute protocol-less link. – Manara

@Manara Isn't what I've shown an absolute link? I thought that's what 1 slash does. – Drumm

It's important to understand that these URLs are not protocol-less, but protocol-relative. They get their protocol from their context, and lacking a context they will act like file urls in most browsers, effectively meaning they break in that they will not load the intended content. While they will work when delivered over http, you'll find that if you save the page and load the exact same HTML from a local file, they will not, because the context is different. The only contexts you should use them in is http vs https. – Stamina

+1, but I'm curious, did your testing include handling protocol-relative links in 301 and 301 redirect headers? – Orthocephalic

@PatrickM: I did not test redirects, no. Only loading JavaScript from the Google CDN. – Thalia

Bingbot is a bad player, getting requests for domain.tld/www.someotherdomain.com/path Headers From: bingbot(at)microsoft.com, User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Real request coming from PTR to domain search.msn.com (A record also resolving back properly) – Holtz

I wouldn't call Dillo "obscure" only because you never heard of it. It's a fine browser when you need to (or want to) go really minimal, without falling back to text only browsers like e.g. lynx. – Radiative

Answer 2

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.

Fructidor

I was thinking exactly the same. What's the point in downloading an external asset over http if it's available over https as well - even if the main site is using http (which it shouldn't, but that's another topic). – Customhouse

@Customhouse the only thing I can think of is avoiding mixed HTTP/HTTPS warnings that might be generated by some browsers – Fructidor

@Ohad_Schneider warnings are triggered only if the document is loaded over secure(https) but assets over unsecure(http). What I was suggesting is that you can always load assets over secure, even if the document is loaded over unsecure. There's no warning and no reason not to use secure, rendering the whole "protocol-relative URL" unnecessary. – Customhouse

@Ohad_Schneider oh sorry, I think I misinterpreted what you were saying. Loading assets over https when you document is over http should not produce any warnings. But loading assets over http when your document is over https does (and probably is blocked by default, at least in Chrome). Were you referring to the case where you serve your site over https and external assets are available only under http? Yeah, that could be an issue but I don't think there's any serious 3rd party service that doesn't serve their content over https, or else they should go out of business anyway. :) – Customhouse

@Customhouse Wut? O_o If someone has HTTPSed site (then) protocol relative URLs won't help to solve getting 3rd party assets over HTTP — no way. And anyways it's better having not that clean-green SSL logo on your HTTPS page than give it up to HTTP back again just due to 3rd parties don't support HTTPS yet. – Efficacious

@Efficacious I'm not sure if I understand you correctly, but if you're saying that it's ok to load HTTP content from HTTPS domain (= mixed content), then you're probably wrong, as browsers are blocking mixed content (and for a good reason, as mixed content defeats the security of your page as it leaves the user vulnerable to man-in-the-middle attacks). See: blog.mozilla.org/tanvi/2013/04/10/… And like I said, if the 3rd party in 2015 does not support HTTPS, then they're probably not trustworthy anyways. One can get HTTPS for free, so why not use it – Customhouse

@Efficacious your assumption that it's better to load http content because some third party don't support https rendering them useless when using https is ridiculous. If you load the document under http, you're making yourself vulnerable to attacks that simply can load any secure/non secure assets. – Treatise

Answer 3

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.

Miracidium

True, however this becomes less and less of a reason to avoid using schemeless URLs as the market share of IE 7 & 8 shrinks. – Stupor

Answer 4

Yes, network-path references were already specified in RFC 1808 and should work with all browsers.

Descendent

It is even recommended and used in the HTML5 boilerplate code: html5boilerplate.com – Ligniform

whit Yes, you do not answer Yes to " Are there any other caveats?" ? ;) – Poetics

@Caspar Kleijne: I explained the Yes with the rest of the sentence. – Descendent

Casper, Gumbo was actually answering the two questions asked: "Is this completely cross-browser compatible? Are there any other caveats?" Yes is the answer to the first question. – Mackle

Answer 5

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.

Rosenblatt

As of 2022, developing from file:// URLs doesn't really work anymore. Modern browsers won't even run JavaScript from local HTML files because doing so has enabled so many security vulnerabilities. Since you can't develop with local files anymore, it is no longer a reason to avoid protocol relative links. – Gilligan

Answer 6

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.

Sarcoid

down-vote for not stating where the additional : is useful. Everywhere I accidentally left the ":" broke the link – Bridesmaid

Answer 7

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

Poolroom