C'è qualche svantaggio per l'utilizzo di una doppia barra iniziale per ereditare il protocollo in un URL? ie src = “// domain.com”

Ho un foglio di stile che carica immagini da un dominio esterno e ne ho bisogno per caricare da https: // da pagine di ordini sicuri e http: // da altre pagine, in base all'URL corrente. Ho scoperto che l'avvio dell'URL con una doppia barra eredita il protocollo corrente. Tutti i browser supportano questa tecnica?

html ex:

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

css ex:

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

Se il browser supporta RFC 1808 Sezione 4 , RFC 2396 Sezione 5.2 o RFC 3986 Sezione 5.2 , utilizzerà effettivamente lo schema dell'URL della pagina per i riferimenti che iniziano con "//".

Se utilizzato su linko @import, IE7 / IE8 scaricherà il file due volte su http://paulirish.com/2010/the-protocol-relative-url/

Aggiornamento dal 2014:

Ora che SSL è incoraggiato per tutti e non ha problemi di prestazioni , questa tecnica è ora un anti-modello . Se la risorsa di cui hai bisogno è disponibile su SSL, usa sempre la https://risorsa.

Un aspetto negativo si verifica se gli URL vengono visualizzati al di fuori del contesto di una pagina Web. Ad esempio, un messaggio di posta elettronica che si trova in un client di posta elettronica (ad esempio Outlook) non ha effettivamente un URL e quando si visualizza un messaggio contenente un URL relativo al protocollo, non esiste alcun contesto di protocollo evidente (il messaggio stesso è indipendente del protocollo utilizzato per recuperarlo, sia esso POP3, IMAP, Exchange, uucp o altro), quindi l'URL non ha alcun protocollo a cui essere relativo. Non ho studiato la compatibilità con i client di posta elettronica per vedere cosa fanno quando viene presentato con un gestore di protocollo mancante. Immagino che la maggior parte prenderà un'ipotesi su http. Apple Mail rifiuta di permetterti di inserire un URL senza protocollo. È analogo al modo in cui gli URL relativi non funzionano nell'e-mail a causa di un contesto altrettanto mancante.

Problemi simili potrebbero verificarsi in altri contesti non HTTP come tweet, messaggi SMS, documenti Word ecc.

La spiegazione più generale è che gli URL di protocollo anonimi non possono funzionare in modo isolato; ci deve essere un contesto rilevante. In una tipica pagina Web è quindi consigliabile inserire una libreria di script in quel modo, ma qualsiasi collegamento esterno dovrebbe sempre specificare un protocollo. Ho provato un semplice test: è //stackoverflow.commappato file:///stackoverflow.comin tutti i browser in cui l'ho provato, quindi non funzionano davvero da soli.

Il motivo potrebbe essere quello di fornire pagine Web portatili. Se la pagina esterna non viene trasportata crittografata (http), perché gli script collegati devono essere crittografati? Questa sembra essere una perdita di prestazioni non necessaria. Nel caso in cui la pagina esterna sia trasportata in modo sicuro crittografato (https), anche il contenuto collegato dovrebbe essere crittografato. Se la pagina è crittografata, il contenuto collegato no, IE sembra emettere un avviso di contenuto misto . Il motivo è che un utente malintenzionato può manipolare gli script lungo la strada. Vedere http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 per una discussione più lunga.

La campagna HTTPS Everywhere di EFF suggerisce di utilizzare https ogni volta che è possibile. Oggi abbiamo la capacità del server di servire pagine Web sempre crittografate.

Solo per completezza. Questo è stato menzionato in un altro thread:

Le "due barre in avanti" sono una scorciatoia comune per "qualunque protocollo sia attualmente utilizzato"

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

Si prega di controllare il thread completo.

Sembra essere una tecnica abbastanza comune ora. Non vi è alcun aspetto negativo, aiuta solo a unificare il protocollo per tutte le risorse sulla pagina, quindi dovrebbe essere usato ove possibile.