Posso cambiare tutti i miei link http: // in solo //?

240

Dave Ward dice:

Non è esattamente una lettura leggera, ma la sezione 4.2 di RFC 3986 fornisce URL completamente qualificati che omettono del tutto il protocollo (HTTP o HTTPS). Quando viene omesso il protocollo di un URL, il browser utilizza invece il protocollo del documento sottostante.

In parole povere, questi URL "senza protocollo" consentono a un riferimento come questo di funzionare in tutti i browser in cui lo proverai:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

All'inizio sembra strano, ma questo URL "senza protocollo" è il modo migliore per fare riferimento a contenuti di terze parti disponibili tramite HTTP e HTTPS.

Ciò risolverebbe sicuramente un sacco di errori di contenuto misto che stiamo vedendo sulle pagine HTTP, supponendo che le nostre risorse siano disponibili sia tramite HTTP che HTTPS.

Questo è completamente compatibile con più browser? Ci sono altri avvertimenti?

http  url  https  protocol-relative 
— un secchione pagato
fonte
Ho letto di questa tecnica sul blog di IE qualche tempo fa. Ma quando l'ho provato non funziona abbastanza bene. Se il mio sito era servito con HTTPS, il browser (Chrome) utilizzava ancora HTTP per URL senza protocollo.
— Christopher Ramírez,
10
ATTENZIONE: ricordarsi di MAI gli URI senza schemi utente nei reindirizzamenti HTTP 3xx !! Le intestazioni HTTP non sono compatibili con questo formato URL. Se è necessario reindirizzare a seconda dello schema, utilizzare mod_rewrite o simile.
— user2596282,
1
@ user2596282 La sperimentazione nelle versioni moderne di Chrome e Firefox non è d'accordo con te, così come la revisione (ancora in bozza) di HTTP 1.1. specifica definita dal gruppo di lavoro HTTPbis (consultare svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Forse quello che dici è vero per alcuni browser, però; conosci qualche particolare che non riesce sugli URL relativi al protocollo nelle intestazioni di posizione?
— Mark Amery,
— Álvaro González,
Non usarli, sono brutti e ridondanti.
— IllidanS4 vuole che Monica ritorni il

Risposte:

204

L'ho provato a fondo prima di pubblicare. Di tutti i browser disponibili per testare su Browsershots , ho trovato solo uno che non gestiva correttamente l'URL relativo del protocollo: un oscuro browser * nix chiamato Dillo .

Ci sono due inconvenienti su cui ho ricevuto feedback:

  1. Gli URL senza protocollo potrebbero non funzionare come previsto quando si "apre" un file locale nel browser, poiché il protocollo di base della pagina sarà file: ///. Soprattutto quando si utilizza l'URL senza protocollo per una risorsa esterna come una risorsa ospitata da CDN. Utilizzo di un server Web locale come Apache o IIS per testare su http: // localhostTuttavia, l' funziona correttamente.
  2. Apparentemente c'è almeno un'app di lettura feed per iPhone che non gestisce correttamente gli URL senza protocollo. Non sono a conoscenza di quale sia il problema o di quanto sia popolare. Per l'hosting di un file JavaScript, questo non è un grosso problema poiché i lettori RSS in genere ignorano comunque il contenuto JavaScript. Tuttavia, potrebbe essere un problema se stai usando questi URL per contenuti multimediali come immagini all'interno di contenuti che devono essere sindacati tramite RSS (anche se questa singola app per lettore su un'unica piattaforma probabilmente rappresenta un numero molto marginale di lettori).
— Dave Ward
fonte
33
Sebbene IE7 / 8 gestisca bene gli URL relativi al protocollo (ovvero URI senza schemi) nella maggior parte dei casi, quando i fogli di stile sono specificati con tali URL, li scaricherà due volte . (Così dice Steve Souders )
— lucasrizoli,
3
Sto scoprendo che IE6 tenta di convertire l'URI in uno relativo (ovvero rimuovendo una delle barre iniziali). Questo è in un linkelemento. Ad esempio, quando si specifica //fonts.googleapis.com/css?family=Rokkitt:400,700, IE6 tenta di caricare http://mysite.com/fonts.googleapis.com/css/<...>. Non così buono!
— CBono,
2
Ho trovato dai miei registri le istanze di quelli che sembrano essere robot spider web (sorgente sconosciuta) che cercano di usare i collegamenti senza protocollo e di non gestirli correttamente.
— Kzqai,
3
Ne ho visto molto nei miei registri, non correlato agli URL senza protocollo. Molti di questi ragni sono scritti incredibilmente male.
— Dave Ward,
11
E 'importante capire che questi URL sono non dal protocollo di meno , ma dal protocollo relativo . Ottengono il loro protocollo dal loro contesto e, in mancanza di un contesto, si comporteranno come URL di file nella maggior parte dei browser, il che significa che interrompono il fatto che non caricheranno il contenuto previsto. Mentre funzioneranno quando consegnati su http, scoprirai che se salvi la pagina e carichi lo stesso HTML esatto da un file locale, non lo faranno, perché il contesto è diverso. L'unico contesto in cui dovresti usarli è http vs https.
— Synchro,
37

La questione se si possano cambiare tutti i loro collegamenti in modo che siano relativi al protocollo può essere controversa, considerando la questione se si debba farlo. Secondo Paul Irish :

17.12.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: // .

— Ohad Schneider
fonte
Stavo pensando esattamente lo stesso. Qual è lo scopo del download di una risorsa esterna su http se è disponibile anche su https, anche se il sito principale utilizza http (cosa che non dovrebbe, ma questo è un altro argomento).
— joonas.fi,
1
@ joonas.fi l'unica cosa a cui riesco a pensare è evitare gli avvisi misti HTTP / HTTPS che potrebbero essere generati da alcuni browser
— Ohad Schneider,
3
Gli avvisi di @Ohad_Schneider vengono attivati ​​solo se il documento viene caricato in modalità protetta (https) ma risorse in condizioni non sicure (http). Quello che stavo suggerendo è che puoi sempre caricare le risorse in modo sicuro, anche se il documento viene caricato in modo non sicuro. Non ci sono avvisi e non c'è motivo di non usare la sicurezza, rendendo inutile l'intero "URL relativo al protocollo".
— joonas.fi,
1
@Ohad_Schneider oh scusa, penso di aver frainteso quello che stavi dicendo. Il caricamento di risorse su https quando si documenta su http non dovrebbe generare alcun avviso. Ma il caricamento di risorse su http quando il documento è su https (e probabilmente è bloccato per impostazione predefinita, almeno in Chrome). Ti riferivi al caso in cui servi il tuo sito su https e le risorse esterne sono disponibili solo in http? Sì, potrebbe essere un problema, ma non credo che ci sia un serio servizio di terze parti che non offra i loro contenuti su https, altrimenti dovrebbero comunque fallire. :)
— joonas.fi,
@ joonas.fi Wut? O_o Se qualcuno ha un sito HTTPS (quindi) gli URL relativi al protocollo non aiuteranno a risolvere il recupero di risorse di terze parti su HTTP - assolutamente no. E comunque è meglio non avere quel logo SSL verde pulito sulla tua pagina HTTPS che restituirlo nuovamente a HTTP solo perché terze parti non supportano ancora HTTPS.
— poige,
15

Sì, i riferimenti al percorso di rete erano già stati specificati in RFC 1808 e dovrebbero funzionare con tutti i browser.

— Gumbo
fonte
11
È anche raccomandato e utilizzato nel codice HTML5 del bollettino: html5boilerplate.com
— Felipe Lima,
1
con Sì, non rispondi Sì a "Ci sono altri avvertimenti?" ? ;)
— Caspar Kleijne,
2
@Caspar Kleijne: ho spiegato il Sì con il resto della frase.
— Gumbo,
1
Casper, Gumbo stava effettivamente rispondendo alle due domande poste: "È completamente compatibile con più browser? Ci sono altri avvertimenti?" Sì è la risposta alla prima domanda.
— Darren Griffith,
4

Questo è completamente compatibile con più browser? Ci sono altri avvertimenti?

Solo per lanciarlo nel mix, se si sta sviluppando su un server locale, potrebbe non funzionare. Devi specificare uno schema, altrimenti il ​​browser potrebbe supporre che lo src="//cdn.example.com/js_file.js"siasrc="file://cdn.example.com/js_file.js" , il che si interromperà poiché non stai ospitando questa risorsa localmente.

Microsoft Internet Explorer sembra essere particolarmente sensibile a questo, vedi questa domanda: Impossibile caricare jQuery in Internet Explorer su localhost (WAMP)

Probabilmente proveresti sempre a trovare una soluzione che funzioni su tutti i tuoi ambienti con il minor numero di modifiche necessarie.

La soluzione utilizzata da HTML5Boilerplate è avere un fallback quando la risorsa non viene caricata correttamente, ma funziona solo se si incorpora un controllo:

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

Ho pubblicato questa risposta anche qui .

AGGIORNAMENTO: HTML5Boilerplate ora utilizza <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">dopo aver deciso di deprecare gli URL relativi al protocollo, vedere qui .

— bg17aw
fonte
1

Non ho riscontrato questi problemi quando si utilizza: //domain.com - ma all'inizio è necessario aggiungere i due punti. Qualche tempo fa Yoast aveva scritto bene su questo. Ma è perso nella sua pila di post sul blog.

— user1431784
fonte
sottovalutazione per non aver dichiarato dove l'ulteriore: è utile. Dappertutto ho lasciato accidentalmente il segno ":" interrotto il collegamento
— rubato il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.