Why would you use document.location.protocol instead of plain // prefixed urls?

Question

For instance Google Analytics uses document.location.protocol in the boilerplate for tracking:

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

instead of

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = '//www.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

The ssl. sub-domain is a mute argument as https://www.google-analytics.com/ga.js works perfectly well.

Knowing Google this most likely is not an oversight. Is there an issue with certain browsers not supporting the // protocol honouring shorthand or is there something else I'm missing?

EDIT: This does not just apply to Google Analytics (different sub-domain example). The same thing appears on the Font Loader API page:

wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
    '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';

Answer 1

At least has one problem in IE because it causes double downloads: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

Answer 2

Indeed, it was not an oversight by the GA Team!
GA loader loads a script, so that's not affected by the double-download bug on a <link> or @import for a stylesheets in IE7/IE8.

They use the conditional (ternary) operator on document.location.protocol because of an edge-case bug in IE6 that causes a security-dialog to pop up under certain security settings when requesting from the non-'ssl' subdomain,

as explained by Paul Irish (who worked together with the Google Analytics javascript lead developer on this matter) on his blog: https://www.paulirish.com/2010/the-protocol-relative-url/ from which I quote below:

2011.01.23: But... what about using this on the Google Analytics snippet?

Yes of course, wouldn't that be nice... So I worked with the Google Analytics javascript lead developer (God, I love working at google) to see if we could do this... turns out we can't. There is an edgecase bug in IE6 that causes a dialog to blow up... under some security settings (unsure if they are default) when requesting from the non-'ssl' subdomain. screenshot here. So feel free to take 40 bytes off your GA snippet if you don't care about IE6.. otherwise you're gonna need that ternary operator. `:)`

2011.12.24. Eric Law (from the IE team) chimes on why IE6 doesn't play well GA...

The reason this doesn't work in IE6 is that the server is using SNI to deduce what certificate to return. XP (and thus IE6) doesn't support SNI in the HTTPS stack. See for details.

Answer 3

You already pointed out the difference in the case of Google Analytics, namely that the secure version is on https://ssl. instead of http://www.. While a secure version of the www may work, it could also be different to the ssl version:

• Different certificates for the ssl version and www version.
• Different code on each version.
• Different cookies set, specific to the SSL domain.

I don't know if any of these apply to Google though. From a glance the code looked to be the same.

Answer 4

This Stack Overflow answer makes some good points.

It would be important to explicitly specify the protocol so that the target asset is loaded correctly within a document opened from a local drive (file:) or when using "iframe magic" (about:).

Answer 5

//www.google-analytics.com/ga.js is not an URL per its standard, as it lacks the scheme, which is mandatory. It works and is used, but it remains non conforming to the URL standard.

See RFC3986 §3 :

The scheme and path components are required, though the path may be empty (no characters). When authority is present, the path must either be empty or begin with a slash ("/") character. When authority is not present, the path cannot begin with two slash characters ("//").