É válido substituir http: // por // em um <script src = "http: //…">?

Eu tenho o seguinte elemento:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

Nesse caso, o site é HTTPS, mas também pode ser apenas HTTP. (O arquivo JS está em outro domínio.) Gostaria de saber se é válido fazer o seguinte por uma questão de conveniência:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

Gostaria de saber se é válido remover o http:ou https:?

Parece funcionar em todos os lugares que testei, mas existem casos em que não funciona?

Um URL relativo sem um esquema (http: ou https :) é válido, de acordo com a RFC 3986: "Uniform Resource Identifier (URI): sintaxe genérica", seção 4.2 . Se um cliente engasgar com isso, a culpa é do cliente, porque ele não está em conformidade com a sintaxe do URI especificada na RFC.

Seu exemplo é válido e deve funcionar. Eu mesmo usei esse método de URL relativo em sites com tráfego intenso e não recebi nenhuma reclamação. Além disso, testamos nossos sites no Firefox, Safari, IE6, IE7 e Opera. Todos esses navegadores entendem esse formato de URL.

É garantido que funcione em qualquer navegador convencional (não estou levando em consideração navegadores com menos de 0,05% de participação de mercado). Caramba, ele funciona no Internet Explorer 3.0.

O RFC 3986 define um URI como composto pelas seguintes partes:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

Ao definir URIs relativos ( Seção 5.2 ), você pode omitir qualquer uma dessas seções, sempre começando pela esquerda. No pseudo-código, fica assim:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

O URI que você está descrevendo é um URI relativo sem esquema.

existem casos em que não funciona?

Se a página pai foi carregada file://, provavelmente não funcionará (ela tentará obter o file://cdn.example.com/js_file.jsque, é claro, você também poderia fornecer localmente).

Muitas pessoas chamam isso de URL relativa ao protocolo.

Isso causa um download duplo de arquivos CSS no IE 7 e 8 .

Aqui duplico a resposta em Recursos ocultos do HTML :

Usando um caminho absoluto independente de protocolo:

<img src="//domain.com/img/logo.png"/>

Se o navegador estiver visualizando uma página em SSL por HTTPS, ele solicitará esse recurso com o protocolo https, caso contrário, ele solicitará com HTTP.

Isso evita a terrível mensagem de erro "Esta página contém itens seguros e não seguros" no IE, mantendo todas as solicitações de ativos dentro do mesmo protocolo.

Advertência: Quando usado em uma <link>importação ou @ para uma folha de estilo, o IE7 e o IE8 baixam o arquivo duas vezes . Todos os outros usos, no entanto, estão bem.

É perfeitamente válido deixar de fora o protocolo. A especificação de URL tem sido muito clara sobre isso há anos, e ainda não encontrei um navegador que não o entenda. Não sei por que essa técnica não é mais conhecida; é a solução perfeita para o espinhoso problema de cruzar os limites HTTP / HTTPS. Mais aqui: transições HTTP-https e URLs relativos

existem casos em que não funciona?

Só para colocar isso em ordem, se você estiver desenvolvendo em um servidor local, pode não funcionar. Você precisa especificar um esquema, caso contrário, o navegador pode assumir que src="//cdn.example.com/js_file.js"é src="file://cdn.example.com/js_file.js", o que será interrompido, pois você não está hospedando este recurso localmente.

O Microsoft Internet Explorer parece ser particularmente sensível a isso, consulte esta pergunta: Não é possível carregar o jQuery no Internet Explorer no localhost (WAMP)

Você provavelmente sempre tentaria encontrar uma solução que funcione em todos os seus ambientes com a menor quantidade de modificações necessárias.

A solução usada pelo HTML5Boilerplate é ter um fallback quando o recurso não for carregado corretamente, mas isso só funcionará se você incorporar uma verificação:

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

ATUALIZAÇÃO: o HTML5Boilerplate agora usa <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.jsapós decidir descontinuar URLs relativos ao protocolo, consulte [aqui] [3].

Seguindo a referência do gnud, a seção 5.2 do RFC 3986 diz:

Se o componente do esquema estiver definido, indicando que a referência começa com um nome de esquema, a referência é interpretada como um URI absoluto e pronto. Caso contrário, o esquema do URI de referência é herdado do componente do esquema do URI base .

Então //está correto :-)

Sim, isso está documentado na RFC 3986 , seção 5.2:

(editar: Opa, minha referência RFC estava desatualizada).

É realmente correto, como outras respostas afirmaram. Você deve observar, no entanto, que alguns rastreadores da Web dispararão 404s para eles solicitando-os no seu servidor como se fosse um URL local. (Eles desconsideram a barra dupla e a tratam como uma barra única).

Você pode configurar uma regra em seu servidor da web para capturá-las e redirecioná-las.

Por exemplo, com o Nginx, você adicionaria algo como:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

Observe, porém, que se você usar períodos em seus URIs, precisará aumentar a especificidade ou isso acabará redirecionando essas páginas para domínios inexistentes.

Além disso, esse é um regex bastante massivo para ser executado em cada consulta - na minha opinião, vale a pena punir navegadores não compatíveis com 404s por um (leve) desempenho atingido na maioria dos navegadores compatíveis.

Estamos vendo erros 404 em nossos logs ao usar //somedomain.com como referências a arquivos JS.

As referências que causam os 404s aparecem assim: ref:

<script src="//somedomain.com/somescript.js" />

Solicitação 404:

http://mydomain.com//somedomain.com/somescript.js

Com isso aparecendo regularmente em nossos registros do servidor da Web, é seguro dizer que: Todos os navegadores e Bots NÃO respeitam a RFC 3986, seção 4.2. A aposta mais segura é incluir o protocolo sempre que possível.

1. Resumo

Resposta para 2019: você ainda pode usar URLs relativos ao protocolo, mas essa técnica é um antipadrão .

Além disso:

1. Você pode ter problemas no desenvolvimento.
2. Algumas ferramentas de terceiros podem não suportá-las.

Migrar de URLs relativos ao protocolo para https://ele seria bom.

2. Relevância

Esta resposta é relevante para janeiro de 2019. No futuro, os dados desta resposta podem estar obsoletos.

3. Anti-padrão

3.1 Argumentação

Paul Irish - engenheiro front-end e defensor do desenvolvedor do Google Chrome - escreveu em 2014, dezembro :

Agora que o SSL é incentivado para todos e não tem problemas de desempenho , essa técnica agora é um antipadrão . Se o ativo necessário estiver disponível em SSL, use sempre ohttps:// .

Permitir que o snippet solicite por HTTP abre a porta para ataques como o recente ataque do lado do GitHub . É sempre seguro solicitar recursos HTTPS, mesmo que seu site esteja em HTTP; no entanto, o contrário não é verdadeiro .

3.2 Outros links

• Carrega recursos da página usando URIs relativos ao protocolo
• Parar de usar URLs relativos ao protocolo

3.3 Exemplos

• Em 2017, o Stack Overflow mudou de URLs relativos ao protocolo para https
• Em 2018, o Chrome sinalizará todos os sites não criptografados como "não seguros"

4. Processo de desenvolvimento

Por exemplo, tento usar o console limpo .

• Arquivo de exemplo KiraCleanConsole__cdn_links_demo.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>

• resultado:

D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

Ligação //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js é válido, mas estou recebendo um erro.

Preste atenção file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jse leia as respostas Thilo e bg17aw sobrefile:// .

Eu não sabia sobre esse comportamento e não conseguia entender por que tenho problemas como esse para pageres .

5. Ferramentas de terceiros

Eu uso o pacote de texto sublime de URLs clicáveis . Use-o, eu posso simplesmente abrir links do meu editor de texto no navegador.

Os dois links no exemplo são válidos. Mas o primeiro link que posso abrir com sucesso no navegador usa URLs clicáveis, segundo link - não. Isso pode não ser muito conveniente.

6. Conclusão

Sim:

1. Se você tiver problemas como no Developing processitem, poderá definir seu fluxo de trabalho de desenvolvimento.
2. Caso contrário, você tem problemas, como no Third-party toolsitem, você pode contribuir com ferramentas.

Mas você não precisa desses problemas adicionais. Leia as informações por links no Anti-patternitem: URLs relativas ao protocolo estão obsoletas.

O padrão que vejo no html5-boilerplate é:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

Ele roda sem problemas em diferentes esquemas como http, https, file.

Como seu exemplo está vinculando a um domínio externo, se você estiver usando HTTPS, verifique se o domínio externo também está configurado para SSL. Caso contrário, seus usuários poderão ver erros SSL e / ou 404 (por exemplo, versões mais antigas do Plesk armazenam HTTP e HTTPS em pastas separadas). Para CDNs, não deve ser um problema, mas para qualquer outro site.

Em uma nota lateral, testado enquanto atualizamos um site antigo e também funciona na parte url = de um META REFRESH.