C'è qualche svantaggio nell'usare una doppia barra leader per ereditare il protocollo in un URL? es. src = "// domain.com"

Question

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

html es:

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

css es:

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

Answer 1

Se il browser supporta RFC 1808 Section 4, RFC 2396 Section 5.2 o RFC 3986 Section 5.2, allora sarà davvero utilizzare lo schema di pagina URL per i riferimenti che iniziano con " //".

Answer 2

Quando viene utilizzato su una link o @import, IE7/IE8 sarà scaricare il file due volte al http://paulirish.com/2010/the-protocol-relative-url/

Aggiornamento dal 2014:

Ora che SSL è encouraged for everyone e doesn’t have performance concerns, questa tecnica è ormai un anti-pattern. Se la risorsa di cui hai bisogno è disponibile su SSL, quindi sempre utilizza la risorsa https://.

Answer 3

Uno svantaggio si verifica se i tuoi URL sono 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 alcun URL e quando si visualizza un messaggio contenente un URL relativo al protocollo, non esiste affatto un contesto di protocollo ovvio (il messaggio stesso è indipendente del protocollo utilizzato per recuperarlo, sia che si tratti di POP3, IMAP, Exchange, uucp o qualsiasi altra cosa), quindi l'URL non ha alcun protocollo a cui fare riferimento. Non ho esaminato la compatibilità con i client di posta elettronica per vedere cosa fanno quando vengono presentati con un gestore di protocolli mancante. Suppongo che la maggior parte delle persone farà una supposizione su http. Apple Mail si rifiuta di farti inserire un URL senza un protocollo. È analogo al modo in cui gli URL relativi non funzionano nell'e-mail a causa di un contesto simile mancante.

problemi simili possono verificarsi in altri contesti non HTTP come nel tweet, messaggi SMS, documenti Word ecc

La spiegazione più generale è che gli URL di protocollo anonimi non possono lavorare in modo isolato; ci deve essere essere un contesto pertinente. In una tipica pagina web è quindi bene inserire in questo modo una libreria di script, ma ogni link esterno dovrebbe sempre specificare un protocollo. Ho provato un semplice test: //stackoverflow.com mappe a file:///stackoverflow.com in tutti i browser in cui l'ho provato, quindi loro in realtà non funzionano da soli.

Answer 4

La ragione potrebbe essere quella 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 deve essere crittografato. Se la pagina è crittografata, non il contenuto collegato, IE sembra emettere un avviso Contenuti misti. Il motivo è che un utente malintenzionato può manipolare gli script durante il percorso. Vedi 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 quando possibile.In questi giorni abbiamo la capacità del server di servire le pagine Web sempre crittografate.

Answer 5

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

'The two forward slashes are a common shorthand for whatever protocol is being used right'

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

Si prega di controllare l'intero thread.

Answer 6

Sembra essere una tecnica abbastanza comune ora. Non ci sono aspetti negativi, aiuta solo a unificare il protocollo per tutte le risorse sulla pagina, quindi dovrebbe essere usato ovunque possibile.