Bisakah saya mengubah semua tautan http: // menjadi // saja?

240

Dave Ward berkata,

Ini bukan pembacaan yang ringan, tetapi bagian 4.2 dari RFC 3986 menyediakan URL yang sepenuhnya memenuhi syarat yang menghilangkan protokol (HTTP atau HTTPS) sama sekali. Ketika protokol URL dihilangkan, browser menggunakan protokol dokumen yang mendasarinya sebagai gantinya.

Sederhananya, URL "tanpa protokol" ini memungkinkan referensi seperti ini berfungsi di setiap browser tempat Anda akan mencobanya:

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

Awalnya terlihat aneh, tetapi URL "kurang protokol" ini adalah cara terbaik untuk mereferensikan konten pihak ketiga yang tersedia melalui HTTP dan HTTPS.

Ini tentu akan menyelesaikan banyak kesalahan konten campuran yang kami lihat di halaman HTTP - dengan asumsi bahwa aset kami tersedia melalui HTTP dan HTTPS.

Apakah ini sepenuhnya kompatibel dengan browser? Apakah ada peringatan lain?

http  url  https  protocol-relative 
— kutu buku yang dibayar
sumber
Saya membaca tentang teknik ini di blog IE beberapa waktu lalu. Tetapi ketika saya mencobanya tidak bekerja dengan baik. Jika situs saya disajikan dengan HTTPS, browser (Chrome) masih menggunakan HTTP untuk URL tanpa protokol.
— Christopher Ramírez
10
PERINGATAN: ingatlah untuk TIDAK PERNAH URI pengguna yang tidak memiliki skema dalam pengalihan HTTP 3xx !! Header HTTP tidak kompatibel dengan format URL ini. Jika Anda perlu mengarahkan ulang tergantung pada skema, gunakan mod_rewrite atau yang serupa.
— user2596282
1
@ user2596282 Eksperimen dalam versi modern Chrome dan Firefox tidak setuju dengan Anda, seperti halnya revisi (masih dalam konsep) ke HTTP 1.1. spec yang ditentukan oleh kelompok kerja HTTPbis (lihat svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Mungkin apa yang Anda katakan adalah benar untuk beberapa browser; Anda tahu ada yang gagal pada URL relatif protokol di header lokasi?
— Mark Amery
— vlvaro González
Jangan menggunakannya, mereka jelek dan berlebihan.
— IllidanS4 ingin Monica kembali

Jawaban:

204

Saya mengujinya dengan seksama sebelum menerbitkan. Dari semua browser yang tersedia untuk diuji pada Browser , saya hanya bisa menemukan satu yang tidak menangani URL relatif protokol dengan benar: browser * nix yang tidak jelas yang disebut Dillo .

Ada dua kelemahan yang saya terima tentang:

  1. URL tanpa protokol mungkin tidak berfungsi seperti yang diharapkan ketika Anda "membuka" file lokal di browser Anda, karena protokol dasar halaman akan berupa file: ///. Terutama ketika Anda menggunakan URL tanpa protokol untuk sumber daya eksternal seperti aset yang di-host CDN. Menggunakan server web lokal seperti Apache atau IIS untuk menguji terhadap http: // alamat localhost berfungsi dengan baik.
  2. Tampaknya ada setidaknya satu aplikasi pembaca feed iPhone yang tidak menangani URL tanpa protokol dengan benar. Saya tidak tahu yang mana yang memiliki masalah atau seberapa populernya masalah itu. Untuk hosting file JavaScript, itu bukan masalah besar karena pembaca RSS biasanya mengabaikan konten JavaScript. Namun, ini bisa menjadi masalah jika Anda menggunakan URL ini untuk media seperti gambar di dalam konten yang perlu disindikasikan melalui RSS (meskipun, aplikasi pembaca tunggal ini pada platform tunggal mungkin menyumbang jumlah pembaca yang sangat kecil).
— Dave Ward
sumber
33
Meskipun IE7 / 8 menangani URL relatif protokol (alias. Schemeless URI) dengan baik dalam kebanyakan kasus, ketika stylesheet ditentukan dengan URL tersebut, itu akan mengunduhnya dua kali . (Demikian kata Steve Souders )
— lucasrizoli
3
Saya menemukan bahwa upaya IE6 untuk mengkonversi URI ke yang relatif (yaitu menghapus salah satu garis miring terkemuka). Ini ada dalam linkelemen. Misalnya, ketika menentukan //fonts.googleapis.com/css?family=Rokkitt:400,700, IE6 mencoba memuat http://mysite.com/fonts.googleapis.com/css/<...>. Tidak begitu baik!
— CBono
2
Saya telah menemukan dari contoh log saya tentang apa yang tampaknya robot web spider (sumber tidak diketahui) mencoba menggunakan tautan tanpa protokol dan tidak menanganinya dengan benar.
— Kzqai
3
Saya telah melihat banyak hal di log saya, tidak terkait dengan URL tanpa protokol. Banyak laba-laba yang ditulis dengan sangat buruk.
— Dave Ward
11
Penting untuk dipahami bahwa URL ini bukan protokol- kurang , tetapi protokol- relatif . Mereka mendapatkan protokol mereka dari konteks mereka, dan tidak memiliki konteks mereka akan bertindak seperti url file di sebagian besar browser, secara efektif berarti mereka memutuskan bahwa mereka tidak akan memuat konten yang dimaksud. Meskipun mereka akan bekerja ketika dikirim melalui http, Anda akan menemukan bahwa jika Anda menyimpan halaman dan memuat HTML yang sama persis dari file lokal, mereka tidak akan melakukannya, karena konteksnya berbeda. Satu-satunya konteks tempat Anda menggunakannya adalah http vs https.
— Sinkronisasi
37

Pertanyaan apakah seseorang dapat mengubah semua tautannya menjadi protokol-relatif dapat diperdebatkan, mempertimbangkan pertanyaan apakah seseorang harus melakukannya. Menurut Paul Irish :

2014.12.17: 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.

— Ohad Schneider
sumber
Saya berpikir persis sama. Apa gunanya mengunduh aset eksternal melalui http jika juga tersedia di https - bahkan jika situs utama menggunakan http (yang seharusnya tidak, tapi itu topik lain).
— joonas.fi
1
@ joonas.fi satu-satunya hal yang dapat saya pikirkan adalah menghindari peringatan HTTP / HTTPS campuran yang mungkin dihasilkan oleh beberapa browser
— Ohad Schneider
3
@Ohad_Schneider peringatan dipicu hanya jika dokumen dimuat lebih aman (https) tetapi aset lebih tidak aman (http). Apa yang saya sarankan adalah bahwa Anda selalu dapat memuat aset lebih aman, bahkan jika dokumen dimuat lebih dari tidak aman. Tidak ada peringatan dan tidak ada alasan untuk tidak menggunakan aman, membuat seluruh "URL relatif protokol" tidak perlu.
— joonas.fi
1
@Ohad_Schneider oh maaf, saya pikir saya salah menafsirkan apa yang Anda katakan. Memuat aset lebih dari https ketika Anda mendokumentasikan lebih dari http seharusnya tidak menghasilkan peringatan. Tetapi memuat aset melalui http saat dokumen Anda melebihi https (dan mungkin diblokir secara default, setidaknya di Chrome). Apakah Anda merujuk pada kasus di mana Anda melayani situs Anda di atas https dan aset eksternal hanya tersedia di bawah http? Ya, itu bisa menjadi masalah tapi saya tidak berpikir ada layanan pihak ke-3 yang serius yang tidak menayangkan konten mereka di https, atau mereka harus keluar dari bisnis. :)
— joonas.fi
@ joonas.fi Wut? O_o Jika seseorang memiliki situs HTTPSed (maka) URL relatif protokol tidak akan membantu menyelesaikan mendapatkan aset pihak ke-3 melalui HTTP - tidak mungkin. Dan bagaimanapun, lebih baik tidak memiliki logo SSL hijau-bersih di halaman HTTPS Anda daripada memberikannya kembali HTTP hanya karena pihak ke-3 belum mendukung HTTPS.
— poige
15

Ya, referensi jalur jaringan sudah ditentukan dalam RFC 1808 dan harus bekerja dengan semua browser.

— Gumbo
sumber
11
Ia bahkan direkomendasikan dan digunakan dalam kode boilerplate HTML5: html5boilerplate.com
— Felipe Lima
1
Sedikit pun Ya, Anda tidak menjawab Ya untuk "Apakah ada peringatan lain?" ? ;)
— Caspar Kleijne
2
@Caspar Kleijne: Saya menjelaskan YA dengan sisa kalimat.
— Gumbo
1
Casper, Gumbo sebenarnya menjawab dua pertanyaan yang diajukan: "Apakah ini sepenuhnya lintas-browser yang kompatibel? Apakah ada peringatan lain?" Ya adalah jawaban untuk pertanyaan pertama.
— Darren Griffith
4

Apakah ini sepenuhnya kompatibel dengan browser? Apakah ada peringatan lain?

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>

Saya mengirim jawaban ini di sini juga.

PEMBARUAN: HTML5Boilerplate sekarang digunakan <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">setelah memutuskan untuk mencabut URL relatif protokol, lihat di sini .

— bg17aw
sumber
1

Saya belum memiliki masalah ini saat menggunakan: //domain.com - tetapi Anda harus menambahkan titik dua di awal. Yoast menulis yang baik tentang ini beberapa waktu lalu. Tapi itu hilang di tumpukan posting blognya.

— pengguna1431784
sumber
turunkan suara untuk tidak menyatakan di mana tambahan: berguna. Di mana-mana saya tidak sengaja meninggalkan ":" memutus tautan
— rob
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.