Existe alguma desvantagem em usar uma barra dupla para herdar o protocolo em uma URL? ou seja, src = “// domain.com”

Eu tenho uma folha de estilo que carrega imagens de um domínio externo e eu preciso que ele seja carregado de https: // de páginas de pedidos seguras e http: // de outras páginas, com base no URL atual. Descobri que iniciar a URL com uma barra dupla herda o protocolo atual. Todos os navegadores suportam essa técnica?

html ex:

 

css ex:

 .class { background: url(https://cdn.domain.com/logo.png); } 

Se o navegador suportar RFC 1808 Seção 4 , RFC 2396 Seção 5.2 ou RFC 3986 Seção 5.2 , então, de fato, usará o esquema da URL da página para referências que começam com “//”.

Quando usado em um link ou @import , o IE7 / IE8 @import o arquivo duas vezes por http://paulirish.com/2010/the-protocol-relative-url/

Atualização de 2014:

Agora que o SSL é incentivado para todos e não tem preocupações de desempenho , essa técnica é agora um anti-padrão . Se o ativo necessário estiver disponível no SSL, use sempre o recurso https:// .

Uma desvantagem ocorre se seus URLs forem visualizados fora do contexto de uma página da web. Por exemplo, uma mensagem de e-mail em um cliente de e-mail (digamos, Outlook) não tem URL e, quando você está exibindo uma mensagem contendo um URL relativo a protocolo, não há nenhum contexto de protocolo óbvio (a mensagem é independente) do protocolo usado para obtê-lo, seja POP3, IMAP, Exchange, uucp ou qualquer outra coisa, portanto, o URL não tem nenhum protocolo a ser relativo. Eu não investiguei a compatibilidade com clientes de e-mail para ver o que eles fazem quando apresentados a um manipulador de protocolo ausente – acredito que a maioria considerará o http. O Apple Mail se recusa a permitir que você insira uma URL sem um protocolo. É análogo ao modo como os URLs relativos não funcionam no email devido a um contexto similar ausente.

Problemas semelhantes podem ocorrer em outros contextos não HTTP, como em tweets, mensagens SMS, documentos do Word etc.

A explicação mais geral é que URLs de protocolo anônimo não podem funcionar isoladamente; deve haver um contexto relevante. Em uma página da Web típica, é muito bom include uma biblioteca de scripts dessa maneira, mas os links externos sempre devem especificar um protocolo. Eu tentei um teste simples: //stackoverflow.com mapeia para file:///stackoverflow.com em todos os navegadores que eu experimentei, então eles realmente não funcionam sozinhos.

O motivo poderia ser fornecer páginas da web portáteis. Se a página externa não é transportada criptografada (http), por que os scripts vinculados devem ser criptografados? Esta parece ser uma perda de desempenho desnecessária. No caso, a página externa é criptografada com segurança (https), e o conteúdo vinculado também deve ser criptografado. Se a página estiver criptografada, o conteúdo vinculado não, o IE parece emitir um aviso de Conteúdo misto . A razão é que um invasor pode manipular os scripts no caminho. Consulte http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 para uma discussão mais longa.

A campanha HTTPS Everywhere do EFF sugere o uso de https sempre que possível. Temos a capacidade do servidor nos dias de hoje para atender a páginas da web sempre criptografadas.

Apenas por completude. Isso foi mencionado em outro segmento:

“As duas barras são uma forma comum de usar qualquer protocolo que esteja sendo usado corretamente”

 if (plain http environment) { use 'http://example.com/my-resource.js' } else { use 'https://example.com/my-resource.js' } 

Por favor, verifique o tópico completo.

Parece ser uma técnica bastante comum agora. Não há desvantagem, apenas ajuda a unificar o protocolo para todos os ativos na página, portanto, deve ser usado sempre que possível.