Por que você usaria document.location.protocol em vez de urls simples / com prefixo?

Por exemplo, o Google Analytics usa document.location.protocol no padrão para rastreamento:

<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>

ao invés de

<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>

O ssl. subdomínio é um argumento mudo, pois https://www.google-analytics.com/ga.js funciona perfeitamente bem.

Conhecer o Google com maior probabilidade não é um descuido. Existe algum problema com certos navegadores que não suportam o protocolo // que honra a taquigrafia ou há algo mais que estou faltando?

EDIT: isso não se aplica apenas ao Google Analytics (exemplo de subdomínio diferente). O mesmo aparece na página da API do carregador de fontes :

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

Na verdade, não foi uma supervisão da equipe do GA!
O carregador do GA carrega um script, para que não seja afetado pelo bug de download duplo em uma <link>ou @importpara uma folha de estilo no IE7 / IE8.

Eles usam o operador condicional (ternário) document.location.protocol devido a um erro de borda no IE6 que faz com que um diálogo de segurança apareça sob certas configurações de segurança ao solicitar o subdomínio não 'ssl' , conforme explicado por Paul Irish (que trabalhou juntamente com o desenvolvedor líder de javascript do Google Analytics sobre esse assunto) em seu blog: https://www.paulirish.com/2010/the-protocol-relative-url/, do qual cito abaixo:

01.01.2011: Mas ... que tal usar isso no snippet do Google Analytics ?

Sim, claro, isso não seria legal ... Então, trabalhei com o desenvolvedor líder de javascript do Google Analytics (Deus, adoro trabalhar no google) para ver se poderíamos fazer isso ... acontece que não podemos. Há um erro do edgecase no IE6 que faz com que uma caixa de diálogo seja explodida ... sob algumas configurações de segurança (sem saber se elas são padrão) ao solicitar o subdomínio não 'ssl'. captura de tela aqui . Portanto, fique à vontade para retirar 40 bytes do seu snippet do GA se você não se importa com o IE6. Caso contrário, precisará desse operador ternário. `:)`

2011.12.24. Eric Law (da equipe do IE) fala sobre por que o IE6 não joga bem GA ...

O motivo para isso não funcionar no IE6 é que o servidor está usando o SNI para deduzir qual certificado retornar. O XP (e, portanto, o IE6) não suporta SNI na pilha HTTPS . Veja para detalhes .

Há pelo menos um problema no IE porque causa downloads duplos: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

Você já apontou a diferença no caso do Google Analytics, ou seja, a versão segura está https://ssl.ativada em vez de http://www.. Embora uma versão segura do www possa funcionar, também pode ser diferente da versão ssl:

• Certificados diferentes para a versão ssl e a versão www.
• Código diferente em cada versão.
• Conjunto de cookies diferentes, específico para o domínio SSL.

Não sei se algum deles se aplica ao Google. À primeira vista, o código parecia o mesmo.

Esta resposta de estouro de pilha faz alguns bons pontos.

Seria importante especificar explicitamente o protocolo para que o ativo de destino seja carregado corretamente em um documento aberto a partir de uma unidade local ( file:) ou ao usar "iframe magic" ( about:).

//www.google-analytics.com/ga.jsnão é um URL de acordo com seu padrão, pois não possui o esquema, o que é obrigatório. Ele funciona e é usado, mas permanece não conforme com o padrão de URL.

Veja RFC3986 §3:

Os componentes do esquema e caminho são necessários, embora o caminho possa estar vazio (sem caracteres). Quando a autoridade está presente, o caminho deve estar vazio ou começar com um caractere de barra ("/"). Quando a autoridade não está presente, o caminho não pode começar com dois caracteres de barra ("//").