Apakah valid untuk mengganti http: // dengan // di <script src = “http: // ...”>?

Saya memiliki elemen berikut:

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

Dalam hal ini situs tersebut adalah HTTPS, tetapi situs tersebut mungkin juga hanya HTTP. (File JS ada di domain lain.) Saya ingin tahu apakah valid untuk melakukan hal berikut demi kenyamanan:

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

Saya ingin tahu apakah ini valid untuk menghapus http:atau https:?

Tampaknya berfungsi di mana pun saya telah menguji, tetapi apakah ada kasus di mana tidak berfungsi?

URL relatif tanpa skema (http: atau https :) valid, per RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax", Bagian 4.2 . Jika klien tersedak, maka itu adalah kesalahan klien karena mereka tidak mematuhi sintaks URI yang ditentukan dalam RFC.

Contoh Anda valid dan harus bekerja. Saya telah menggunakan metode URL relatif itu sendiri di situs-situs yang sangat diperdagangkan dan tidak memiliki keluhan. Kami juga menguji situs kami di Firefox, Safari, IE6, IE7 dan Opera. Semua browser ini memahami format URL itu.

Dijamin bekerja di semua browser arus utama (Saya tidak mempertimbangkan browser dengan pangsa pasar kurang dari 0,05%). Heck, itu bekerja di Internet Explorer 3.0.

RFC 3986 mendefinisikan URI sebagai terdiri dari bagian-bagian berikut:

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

Saat mendefinisikan URI relatif ( Bagian 5.2 ), Anda dapat menghilangkan bagian mana saja, selalu dimulai dari kiri. Dalam pseudo-code, tampilannya seperti ini:

 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;

URI yang Anda gambarkan adalah URI relatif tanpa skema.

Adakah kasus yang tidak berfungsi?

Jika halaman induk diambil dari file://, maka itu mungkin tidak berfungsi (itu akan mencoba untuk mendapatkannya file://cdn.example.com/js_file.js, yang tentu saja Anda bisa berikan secara lokal juga).

Banyak orang menyebutnya URL Relatif Protokol.

Ini menyebabkan pengunduhan dua kali file CSS di IE 7 & 8 .

Di sini saya menggandakan jawabannya dalam fitur Tersembunyi dari HTML :

Menggunakan jalur absolut independen-protokol:

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

Jika browser melihat halaman dalam SSL melalui HTTPS, maka browser akan meminta aset itu dengan protokol https, jika tidak maka akan memintanya dengan HTTP.

Ini mencegah pesan galat "Halaman ini berisi item aman dan tidak aman" di IE, menjaga semua permintaan aset Anda dalam protokol yang sama.

Peringatan: Ketika digunakan pada <link>atau @import untuk stylesheet, IE7 dan IE8 mengunduh file dua kali . Namun, semua kegunaan lain baik-baik saja.

Sangat valid untuk meninggalkan protokol. URL spec sudah sangat jelas tentang hal ini selama bertahun-tahun, dan saya belum menemukan browser yang tidak memahaminya. Saya tidak tahu mengapa teknik ini tidak lebih dikenal; itu solusi sempurna untuk masalah pelik batas HTTP / HTTPS. Lebih lanjut di sini: Transisi Http-https dan URL relatif

Adakah kasus yang tidak berfungsi?

Hanya dengan melempar ini dalam campuran, jika Anda mengembangkan pada server lokal, itu mungkin tidak berfungsi. Anda harus menentukan skema, jika tidak browser mungkin menganggap bahwa src="//cdn.example.com/js_file.js"adalah src="file://cdn.example.com/js_file.js", yang akan memecah karena Anda tidak hosting sumber daya ini secara lokal.

Microsoft Internet Explorer tampaknya sangat sensitif terhadap ini, lihat pertanyaan ini: Tidak dapat memuat jQuery di Internet Explorer di localhost (WAMP)

Anda mungkin akan selalu berusaha menemukan solusi yang berfungsi di semua lingkungan Anda dengan jumlah modifikasi paling sedikit yang diperlukan.

Solusi yang digunakan oleh HTML5Boilerplate adalah memiliki cadangan ketika sumber daya tidak dimuat dengan benar, tetapi itu hanya bekerja jika Anda memasukkan tanda centang:

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

UPDATE: HTML5Boilerplate sekarang digunakan <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.jssetelah memutuskan untuk mencabut URL relatif protokol, lihat [di sini] [3].

Mengikuti referensi gnud, RFC 3986 bagian 5.2 mengatakan:

Jika komponen skema didefinisikan, menunjukkan bahwa referensi dimulai dengan nama skema, maka referensi ditafsirkan sebagai URI absolut dan kita selesai. Jika tidak, skema referensi URI diwarisi dari komponen dasar skema URI .

Jadi //benar :-)

Ya, ini didokumentasikan dalam RFC 3986 , bagian 5.2:

(edit: Ups, referensi RFC saya sudah usang).

Memang benar, seperti jawaban lain telah menyatakan. Anda harus mencatat, bahwa beberapa perayap web akan memulai 404 untuk ini dengan meminta mereka di server Anda seolah-olah URL lokal. (Mereka mengabaikan tebasan ganda dan memperlakukannya sebagai tebasan tunggal).

Anda mungkin ingin mengatur aturan di server web Anda untuk menangkap dan mengarahkannya.

Misalnya, dengan Nginx, Anda akan menambahkan sesuatu seperti:

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

Namun perlu dicatat, bahwa jika Anda menggunakan periode di URI, Anda harus meningkatkan kekhususan atau akhirnya akan mengarahkan ulang halaman tersebut ke domain yang tidak ada.

Juga, ini adalah regex yang agak masif untuk dijalankan untuk setiap permintaan - menurut pendapat saya, layak untuk menghukum browser yang tidak patuh dengan 404s atas (sedikit) pencapaian kinerja pada sebagian besar browser yang patuh.

Kami melihat 404 kesalahan dalam log kami ketika menggunakan //somedomain.com sebagai referensi ke file JS.

Referensi yang menyebabkan 404 keluar tampak seperti ini: ref:

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

404 permintaan:

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

Dengan ini muncul secara teratur di log server web kami, aman untuk mengatakan bahwa: Semua browser dan Bot TIDAK menghormati RFC 3986 bagian 4.2. Taruhan paling aman adalah memasukkan protokol jika memungkinkan.

1. Ringkasan

Jawaban untuk 2019: Anda masih dapat menggunakan URL relatif protokol, tetapi teknik ini anti-pola .

Juga:

1. Anda mungkin memiliki masalah dalam pengembangan.
2. Beberapa alat pihak ketiga mungkin tidak mendukungnya.

Bermigrasi dari URL protokol-relatif ke https://itu akan menyenangkan.

2. Relevansi

Jawaban ini relevan untuk Januari 2019. Di masa mendatang, data dari jawaban ini mungkin sudah usang.

3. Anti-pola

3.1. Argumentasi

Paul Irish - insinyur front-end dan advokat pengembang untuk Google Chrome - menulis pada 2014, Desember :

Sekarang SSL didorong untuk semua orang dan tidak memiliki masalah kinerja , teknik ini sekarang merupakan anti-pola . Jika aset yang Anda butuhkan tersedia di SSL, maka selalu gunakan https://aset tersebut.

Mengizinkan cuplikan meminta melalui HTTP membuka pintu untuk serangan seperti serangan GitHub Man-on-the-side baru-baru ini . Selalu aman untuk meminta aset HTTPS bahkan jika situs Anda menggunakan HTTP, namun kebalikannya tidak benar .

3.2. Tautan lain

• Memuat sumber daya halaman menggunakan URI relatif protokol
• Berhenti menggunakan URL relatif protokol

3.3. Contohnya

• Pada 2017 Stack Overflow beralih dari URL relatif protokol ke https
• Pada tahun 2018 Chrome akan menandai semua situs web yang tidak dienkripsi sebagai “tidak aman”

4. Mengembangkan proses

Sebagai contoh, saya mencoba menggunakan konsol bersih .

• File contoh 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>

• keluaran:

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

Tautan //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsvalid, tetapi saya mendapatkan kesalahan.

Perhatikan file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsdan baca jawaban Thilo dan bg17aw tentang file://.

Saya tidak tahu tentang perilaku ini dan tidak bisa mengerti mengapa saya memiliki masalah seperti ini untuk pager .

5. Alat pihak ketiga

Saya menggunakan paket Teks Sublime URL yang Dapat Diklik. Gunakan itu, saya bisa membuka tautan dari editor teks saya di browser.

Kedua tautan dalam contoh ini valid. Tapi tautan pertama yang berhasil saya buka di browser menggunakan URL yang dapat diklik, tautan kedua - tidak. Ini mungkin tidak nyaman.

6. Kesimpulan

Iya:

1. Jika Anda memiliki masalah seperti pada Developing processitem, Anda dapat mengatur alur kerja pengembangan Anda.
2. Jika Anda memiliki masalah seperti pada Third-party toolsitem, Anda dapat berkontribusi alat.

Tetapi Anda tidak perlu masalah tambahan ini. Baca informasi berdasarkan tautan dalam Anti-patternitem: URL relatif protokol sudah usang.

Pola yang saya lihat di html5-boilerplate adalah:

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

Ini berjalan lancar pada skema yang berbeda seperti http, https, file.

Karena contoh Anda menghubungkan ke domain eksternal, jika Anda menggunakan HTTPS maka Anda harus memverifikasi bahwa domain eksternal juga diatur untuk SSL. Jika tidak, pengguna Anda mungkin melihat kesalahan SSL dan / atau kesalahan 404 (mis. Versi lama Plesk menyimpan HTTP dan HTTPS dalam folder terpisah). Untuk CDN, seharusnya tidak menjadi masalah tetapi untuk situs web lain apa pun bisa.

Di samping catatan, diuji saat memperbarui situs web lama dan juga berfungsi di url = bagian dari META REFRESH.