È valido per sostituire http: // con // in uno <script src = “http: //…”>?

Ho il seguente elemento:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

In questo caso il sito è HTTPS, ma il sito potrebbe anche essere solo HTTP. (Il file JS si trova su un altro dominio.) Mi chiedo se sia valido per fare ciò per comodità:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

Mi chiedo se è valido per rimuovere il http:o https:?

Sembra funzionare ovunque ho provato, ma ci sono casi in cui non funziona?

È valido un URL relativo senza schema (http: o https :), per RFC 3986: "Uniform Resource Identifier (URI): Sintassi generica", Sezione 4.2 . Se un client lo soffoca, è colpa del cliente perché non è conforme alla sintassi URI specificata nell'RFC.

Il tuo esempio è valido e dovrebbe funzionare. Ho usato quel metodo URL relativo anche su siti fortemente trafficati e non ho avuto lamentele. Inoltre, testiamo i nostri siti su Firefox, Safari, IE6, IE7 e Opera. Tutti questi browser comprendono questo formato URL.

È garantito il funzionamento con qualsiasi browser tradizionale (non sto prendendo in considerazione browser con una quota di mercato inferiore allo 0,05%). Diamine, funziona in Internet Explorer 3.0.

RFC 3986 definisce un URI come composto dalle seguenti parti:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

Quando si definiscono gli URI relativi ( Sezione 5.2 ), è possibile omettere una qualsiasi di quelle sezioni, iniziando sempre da sinistra. In pseudo-codice, assomiglia a questo:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

L'URI che stai descrivendo è un URI relativo senza schema.

ci sono casi in cui non funziona?

Se la pagina principale è stata caricata file://, probabilmente non funziona (tenterà di ottenere file://cdn.example.com/js_file.js, cosa che ovviamente potresti fornire anche localmente).

Molte persone chiamano questo un URL relativo al protocollo.

Provoca un doppio download di file CSS in IE 7 e 8 .

Qui duplico la risposta in Funzionalità nascoste di HTML :

Utilizzando un percorso assoluto indipendente dal protocollo:

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

Se il browser visualizza una pagina in SSL tramite HTTPS, richiederà tale risorsa con il protocollo https, altrimenti lo richiederà con HTTP.

Questo evita quel terribile messaggio di errore "Questa pagina contiene elementi sia protetti che non protetti" in IE, mantenendo tutte le richieste di risorse all'interno dello stesso protocollo.

Avvertenza: se utilizzato su <link>o @import per un foglio di stile, IE7 e IE8 scaricano il file due volte . Tutti gli altri usi, tuttavia, vanno bene.

È perfettamente valido lasciare il protocollo. Le specifiche dell'URL sono state molto chiare su questo per anni e devo ancora trovare un browser che non lo capisca. Non so perché questa tecnica non sia meglio conosciuta; è la soluzione perfetta al spinoso problema di attraversare i confini HTTP / HTTPS. Altro qui: transizioni Http-https e relativi URL

ci sono casi in cui non funziona?

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

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

Seguendo il riferimento dello gnud, la sezione 5.2 del RFC 3986 dice:

Se viene definito il componente dello schema, indicando che il riferimento inizia con un nome di schema, il riferimento viene interpretato come un URI assoluto e abbiamo terminato. Altrimenti, lo schema dell'URI di riferimento viene ereditato dal componente dello schema dell'URI di base .

Quindi //è corretto :-)

Sì, questo è documentato in RFC 3986 , sezione 5.2:

(modifica: Spiacenti, il mio riferimento RFC era obsoleto).

È davvero corretto, come hanno affermato altre risposte. Dovresti notare, tuttavia, che alcuni web crawler attivano 404 per questi richiedendoli sul tuo server come se un URL locale. (Ignorano la doppia barra e la trattano come una singola barra).

Potresti voler impostare una regola sul tuo server web per catturarli e reindirizzarli.

Ad esempio, con Nginx, aggiungi qualcosa come:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

Tieni presente, tuttavia, che se utilizzi punti nei tuoi URI, dovrai aumentare la specificità o finirà per reindirizzare tali pagine a domini inesistenti.

Inoltre, questa è una regex piuttosto massiccia da eseguire per ogni query - a mio avviso, vale la pena punire i browser non conformi con 404s su un (lieve) risultato di prestazioni sulla maggior parte dei browser compatibili.

Stiamo riscontrando 404 errori nei nostri registri quando si utilizza //somedomain.com come riferimento ai file JS.

I riferimenti che causano i 404 escono così: ref:

<script src="//somedomain.com/somescript.js" />

404 richiesta:

http://mydomain.com//somedomain.com/somescript.js

Con questi che compaiono regolarmente nei registri del nostro server Web, è sicuro dire che: Tutti i browser e i robot NON rispettano la sezione 4.2 di RFC 3986. La scommessa più sicura è quella di includere il protocollo ogni volta che è possibile.

1. Riepilogo

Risposta per il 2019: è ancora possibile utilizzare URL relativi al protocollo, ma questa tecnica è un anti-pattern .

Anche:

1. Potresti avere problemi nello sviluppo.
2. Alcuni strumenti di terze parti potrebbero non supportarli.

https://Sarebbe bello eseguire la migrazione da URL relativi al protocollo .

2. Rilevanza

Questa risposta è pertinente per gennaio 2019. In futuro, i dati di questa risposta potrebbero essere obsoleti.

3. Anti-pattern

3.1. Argomentazione

Paul Irish - ingegnere front-end e fautore dello sviluppatore per Google Chrome - scrive nel 2014, a dicembre :

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.

Consentire allo snippet di richiedere su HTTP apre la porta ad attacchi come il recente attacco Man-on-the-side di GitHub . È sempre sicuro richiedere risorse HTTPS anche se il tuo sito è su HTTP, tuttavia non è vero il contrario .

3.2. Un altro link

• Carica le risorse della pagina utilizzando gli URI relativi al protocollo
• Smetti di usare gli URL relativi al protocollo

3.3. Esempi

• Nel 2017 Stack Overflow è passato da URL relativi al protocollo a https
• Nel 2018 Chrome contrassegnerà tutti i siti Web non crittografati come "non sicuri"

4. Processo di sviluppo

Ad esempio, provo a utilizzare clean-console .

• File di esempio KiraCleanConsole__cdn_links_demo.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>

• produzione:

D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

Il link //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsè valido, ma viene visualizzato un errore.

Presta attenzione file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jse leggi le risposte a Thilo e bg17awfile:// .

Non sapevo di questo comportamento e non riuscivo a capire perché ho problemi come questo per i pager .

5. Strumenti di terze parti

Uso il pacchetto Sublime Text degli URL cliccabili . Usalo, posso semplicemente aprire i collegamenti dal mio editor di testo nel browser.

Entrambi i collegamenti nell'esempio sono validi. Ma il primo link che posso aprire con successo nel browser usa URL cliccabili, secondo link - no. Questo potrebbe non essere molto conveniente.

6. Conclusione

Sì:

1. In caso di problemi come Developing processnell'articolo, è possibile impostare il flusso di lavoro di sviluppo.
2. Altrimenti hai problemi come Third-party toolsnell'articolo, puoi contribuire con strumenti.

Ma non hai bisogno di questi problemi aggiuntivi. Leggi le informazioni tramite link Anti-patternnell'elemento: gli URL relativi al protocollo sono obsoleti.

Lo schema che vedo su html5-boilerplate è:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

Funziona senza problemi su sistemi diversi, come http, https, file.

Poiché il tuo esempio si collega a un dominio esterno, se stai utilizzando HTTPS, dovresti verificare che anche il dominio esterno sia configurato per SSL. Altrimenti, gli utenti potrebbero visualizzare errori SSL e / o errori 404 (ad es. Versioni precedenti di Plesk archiviano HTTP e HTTPS in cartelle separate). Per i CDN, non dovrebbe essere un problema, ma per qualsiasi altro sito Web potrebbe esserlo.

In una nota a margine, testato mentre si aggiorna un vecchio sito Web e funziona anche in url = parte di un aggiornamento META.