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

244
votes

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?

7
httpurlhttpsprotocol-relative
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. – Christopher Ramírez
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. – user2596282
@user2596282 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? – Mark Amery
Same question with some good answers: Absolute URLs omitting the protocol (scheme) in order to preserve the one of the current page – Álvaro González
Don't use them, they are ugly and redundant. – IS4

7 Answers

205
votes

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).
39
votes

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.

30
votes

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.

15
votes

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

4
votes

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.

1
votes

I have not had these issues when using ://domain.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.

0
votes

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