C’è qualche svantaggio nell’usare una doppia barra leader per ereditare il protocollo in un URL? cioè src = “// dominio.com”

Ho un foglio di stile che carica le immagini da un dominio esterno e ne ho bisogno per caricare da https: // da pagine di ordini sicure 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:

 

css ex:

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

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

Se utilizzato su un link o @import , IE7 / IE8 scaricherà il file due volte per 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 risorsa https:// .

Uno svantaggio si verifica se i tuoi 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 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 potrebbero verificarsi in altri contesti non HTTP come nei tweet, messaggi SMS, documenti Word, ecc.

La spiegazione più generale è che gli URL dei protocolli anonimi non possono funzionare separatamente; ci deve 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 mapping al file:///stackoverflow.com in tutti i browser in cui l’ho provato, quindi in realtà non funzionano da soli.

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 Contenuto misto . 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 ansible. In questi giorni abbiamo la capacità del server di servire le pagine Web sempre crittografate.

Solo per completezza. Questo è stato menzionato in un’altra discussione:

‘Le due barre in avanti sono una scorciatoia comune per qualunque protocollo venga usato correttamente’

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

Si prega di controllare la discussione completa.

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