Mengapa URL peka huruf besar kecil?

Pertanyaan saya: Ketika URL pertama kali dirancang, mengapa sensitivitas huruf menjadi fitur? Saya menanyakan hal ini karena menurut saya (yaitu, orang awam) bahwa case-insensitivity lebih disukai untuk mencegah kesalahan yang tidak perlu dan menyederhanakan serangkaian teks yang sudah rumit.

Juga, adakah tujuan / keuntungan nyata untuk memiliki URL peka huruf besar-kecil (yang bertentangan dengan sebagian besar URL yang mengarah ke halaman yang sama tidak peduli kapitalisasi)?

Wikipedia, misalnya, adalah situs web yang sensitif terhadap huruf besar (kecuali untuk karakter pertama):

https://en.wikipedia.org/wiki/St Sebuah ck_Exchange adalah DOA.

Mengapa URL tidak peka huruf besar-kecil?

Saya mengerti bahwa mungkin terlihat seperti pertanyaan retoris yang provokatif (dan "pendukung setan"), tetapi saya pikir ini berguna untuk dipertimbangkan. Desain HTTP adalah "klien", yang biasa kita sebut "browser web", meminta "server web" untuk data.

Ada banyak, banyak server web berbeda yang dirilis. Microsoft telah merilis IIS dengan sistem operasi Windows Server (dan lainnya, termasuk Windows XP Professional). Unix memiliki kelas berat seperti nginx dan Apache, belum lagi penawaran yang lebih kecil seperti httpd internal OpenBSD, atau thttpd, atau lighttpd. Selain itu, banyak perangkat yang mendukung jaringan telah membuat server web yang dapat digunakan untuk mengonfigurasi perangkat, termasuk perangkat dengan tujuan khusus untuk jaringan, seperti router (termasuk banyak titik akses Wi-Fi, dan modem DSL) dan perangkat lain seperti printer atau UPS (unit catu daya tak terputus yang didukung baterai) yang mungkin memiliki konektivitas jaringan.

Jadi pertanyaannya, "Mengapa URL case-sensitive?", Bertanya, "Mengapa server web memperlakukan URL sebagai case-sensitive?" Dan jawaban sebenarnya adalah: mereka tidak semua melakukan itu. Setidaknya satu server web, yang cukup populer, biasanya TIDAK peka terhadap huruf besar-kecil. (Server web adalah IIS.)

Alasan utama untuk perilaku yang berbeda antara server web yang berbeda mungkin bermuara pada masalah kesederhanaan. Cara sederhana untuk membuat server web adalah dengan melakukan hal-hal dengan cara yang sama seperti bagaimana sistem operasi komputer / perangkat menemukan file. Sering kali, server web mencari file untuk memberikan tanggapan. Unix dirancang di sekitar komputer kelas atas, sehingga Unix menyediakan fungsionalitas yang diinginkan untuk memungkinkan huruf besar dan kecil. Unix memutuskan untuk memperlakukan huruf besar dan kecil sebagai berbeda karena, yah, mereka berbeda. Itu hal yang langsung dan alami untuk dilakukan. Windows memiliki sejarah menjadi case-insensitive karena keinginan untuk mendukung perangkat lunak yang sudah dibuat, dan sejarah ini kembali ke DOS yang sama sekali tidak mendukung huruf kecil, mungkin dalam upaya menyederhanakan hal-hal dengan komputer yang kurang kuat yang menggunakan lebih sedikit memori. Karena sistem operasi ini berbeda, hasilnya adalah server web yang dirancang sederhana (versi awal) mencerminkan perbedaan yang sama.

Sekarang, dengan semua latar belakang itu, berikut adalah beberapa jawaban spesifik untuk pertanyaan spesifik:

Ketika URL pertama kali dirancang, mengapa sensitivitas huruf menjadi fitur?

Kenapa tidak? Jika semua server web standar tidak peka huruf besar kecil, itu akan menunjukkan bahwa server web mengikuti serangkaian aturan yang ditentukan oleh standar. Tidak ada aturan yang mengatakan bahwa kasus itu perlu diabaikan. Alasan bahwa tidak ada aturan hanyalah karena tidak ada alasan untuk ada aturan semacam itu. Mengapa repot-repot membuat aturan yang tidak perlu?

Saya menanyakan hal ini karena menurut saya (yaitu, orang awam) bahwa case-insensitivity lebih disukai untuk mencegah kesalahan yang tidak perlu dan menyederhanakan serangkaian teks yang sudah rumit.

URL dirancang untuk diproses oleh mesin. Meskipun seseorang dapat mengetik URL lengkap ke bilah alamat, itu bukan bagian utama dari desain yang dimaksud. Desain yang dimaksud adalah orang-orang akan mengikuti ("mengklik") tautan Jika orang awam rata-rata melakukan itu, maka mereka benar-benar tidak peduli apakah URL yang tak terlihat itu sederhana atau rumit.

Juga, adakah tujuan / keuntungan nyata untuk memiliki URL peka huruf besar-kecil (yang bertentangan dengan sebagian besar URL yang mengarah ke halaman yang sama tidak peduli kapitalisasi)?

Poin bernomor kelima dari jawaban William Hay menyebutkan satu keunggulan teknis: URL dapat menjadi cara yang efektif bagi peramban web untuk mengirim sedikit informasi ke server web, dan lebih banyak informasi dapat dimasukkan jika ada batasan yang lebih sedikit, jadi sensitivitas huruf besar-kecil pembatasan akan mengurangi seberapa banyak informasi dapat dimasukkan.

Namun, dalam banyak kasus, tidak ada manfaat yang sangat menarik untuk sensitivitas kasus, yang dibuktikan oleh fakta bahwa IIS biasanya tidak peduli dengannya.

Singkatnya, alasan yang paling menarik kemungkinan hanya kesederhanaan bagi mereka yang merancang perangkat lunak server web, terutama pada platform case-sensitive seperti Unix. (HTTP bukan sesuatu yang mempengaruhi desain asli Unix, karena Unix lebih tua dari HTTP.)

URL tidak peka huruf besar-kecil, hanya sebagian saja.
Misalnya, tidak ada yang peka huruf besar-kecil di URL https://google.com,

Dengan mengacu pada RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax

Pertama, dari Wikipedia , sebuah URL terlihat seperti:

 scheme:[//host[:port]][/]path[?query][#fragment]

(Saya sudah menghapus user:passwordbagian itu karena tidak menarik dan jarang digunakan)

• scheme:

Skema tidak peka huruf besar-kecil

• host:

Subkomponen host tidak case-sensitive.

• path:

Komponen jalur berisi data ...

• query:

Komponen kueri berisi data non-hierarkis ...

• fragment:

Jenis media individual dapat menetapkan batasan atau struktur mereka sendiri dalam sintaks pengidentifikasi fragmen untuk menentukan jenis subset, pandangan, atau referensi eksternal yang berbeda.

Jadi, schemedan hosttidak peka huruf besar-kecil.
URL lainnya peka huruf besar-kecil.

Mengapa pathcase-sensitive?

Ini sepertinya menjadi pertanyaan utama.
Sulit untuk menjawab "mengapa" sesuatu dilakukan jika tidak didokumentasikan, tetapi kita dapat membuat tebakan yang sangat baik.
Saya telah mengambil kutipan yang sangat spesifik dari spec, dengan penekanan pada data .
Mari kita lihat lagi URL:

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• Lokasi - Lokasi memiliki bentuk kanonik, dan tidak peka huruf besar-kecil. Mengapa? Mungkin agar Anda bisa membeli nama domain tanpa harus membeli ribuan varian.

• Data - data digunakan oleh server target, dan aplikasi dapat memilih apa artinya . Tidak masuk akal untuk membuat case case tidak sensitif. Aplikasi harus memiliki lebih banyak opsi, dan mendefinisikan case-insensitivity dalam spesifikasi akan membatasi opsi-opsi ini.
  Ini juga merupakan perbedaan yang berguna untuk HTTPS: data dienkripsi , tetapi tuan rumah terlihat.

Apakah itu berguna?

Sensitivitas huruf memiliki kekurangan ketika datang ke caching dan URL kanonik, tetapi tentu berguna. Beberapa contoh:

• Base64 , yang digunakan dalam URI Data .
• Situs dapat menyandikan data Base64 di url, misalnya: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsGAKAgA
• Penyingkat URL menggunakan sensitivitas huruf besar: /a5Bmungkin berbeda dari/a5b
• Seperti yang telah Anda sebutkan, Wikipedia dapat membedakan "AIDS" dari "Aids".

Sederhana. OS peka huruf besar-kecil. Server web umumnya tidak peduli kecuali mereka harus menekan sistem file di beberapa titik. Di sinilah Linux dan sistem operasi berbasis Unix lainnya menegakkan aturan sistem file di mana sensitivitas kasus adalah bagian utama. Inilah sebabnya mengapa IIS tidak pernah peka terhadap kasus; karena Windows tidak pernah case sensitif.

[Memperbarui]

Ada beberapa argumen kuat dalam komentar (sejak dihapus) tentang apakah URL memiliki hubungan dengan sistem file seperti yang telah saya nyatakan. Argumen-argumen ini menjadi panas. Adalah sangat picik untuk percaya bahwa tidak ada hubungan. Benar-benar ada! Biarkan saya jelaskan lebih lanjut.

Pemrogram aplikasi umumnya bukan pemrogram internal sistem. Saya tidak sedang menghina. Mereka adalah dua disiplin ilmu yang terpisah dan pengetahuan sistem internal tidak diperlukan untuk menulis aplikasi ketika aplikasi hanya dapat melakukan panggilan ke OS. Karena pemrogram aplikasi bukan pemrogram internal sistem, memintas layanan OS tidak dimungkinkan. Saya mengatakan ini karena ini adalah dua kubu yang terpisah dan mereka jarang menyeberang. Aplikasi ditulis untuk menggunakan layanan OS sebagai aturan. Tentu saja ada beberapa pengecualian.

Kembali ketika server web mulai muncul, pengembang aplikasi tidak berusaha untuk memotong layanan OS. Ada beberapa alasan untuk ini. Satu, itu tidak perlu. Dua, pemrogram aplikasi umumnya tidak tahu cara mem-bypass layanan OS. Tiga, kebanyakan OS sangat stabil dan kuat, atau sangat sederhana dan ringan dan tidak sepadan dengan biaya.

Perlu diingat bahwa server web awal berjalan pada komputer mahal seperti server DEC VAX / VMS dan Unix of the day (Berkeley dan Ultrix dan juga yang lain) pada komputer bingkai utama atau komputer bingkai tengah, lalu segera setelah pada komputer ringan seperti PC dan Windows 3.1. Ketika mesin pencari yang lebih modern mulai muncul, seperti Google pada tahun 1997/8, Windows telah pindah ke Windows NT dan OS lain seperti Novell dan Linux juga mulai menjalankan server web. Apache adalah server web yang dominan meskipun ada yang lain seperti IIS dan O'Reilly yang juga sangat populer. Tak satu pun dari mereka pada saat itu melewati layanan OS. Kemungkinan tidak ada server web yang dapat melakukan hal ini bahkan sampai hari ini.

Server web awal cukup sederhana. Mereka masih ada sampai sekarang. Setiap permintaan yang dibuat untuk sumber daya melalui permintaan HTTP yang ada pada hard drive adalah / dibuat oleh server web melalui sistem file OS.

Sistem file adalah mekanisme yang agak sederhana. Karena permintaan dibuat untuk akses ke file, jika file itu ada, permintaan tersebut diteruskan ke sub-sistem otorisasi dan jika diberikan, permintaan asli terpenuhi. Jika sumber daya tidak ada atau tidak diotorisasi, pengecualian dilemparkan oleh sistem. Ketika aplikasi mengajukan permintaan, pemicu diatur dan aplikasi menunggu. Ketika permintaan dijawab, pemicu dilemparkan dan aplikasi memproses respons permintaan. Masih bekerja seperti itu sampai sekarang. Jika aplikasi melihat bahwa permintaan telah terpenuhi itu terus, jika gagal, aplikasi mengeksekusi kondisi kesalahan dalam kode itu atau mati jika tidak ditangani. Sederhana.

Dalam kasus server web, dengan asumsi bahwa permintaan URL untuk path / file dibuat, server web mengambil path / file bagian dari permintaan URL (URI) dan membuat permintaan ke sistem file dan itu baik puas atau melempar pengecualian. Server web kemudian memproses respons. Jika, misalnya, jalur dan file yang diminta ditemukan dan akses diberikan oleh sub-sistem otorisasi, maka server web memproses permintaan I / O seperti biasa. Jika sistem file melempar pengecualian, maka server web mengembalikan kesalahan 404 jika file tidak ditemukan atau 403 dilarang jika kode alasan tidak sah.

Karena beberapa OS peka huruf besar-kecil dan sistem file jenis ini membutuhkan pencocokan sama persis, jalur / file yang diminta dari server web harus sama persis dengan apa yang ada di hard drive. Alasannya sederhana. Server web tidak menebak apa yang Anda maksud. Tidak ada komputer yang melakukannya tanpa diprogram. Server web hanya memproses permintaan saat mereka menerimanya. Jika bagian jalur / file dari permintaan URL diteruskan langsung ke sistem file tidak cocok dengan apa yang ada di hard drive, maka sistem file melempar pengecualian dan server web mengembalikan kesalahan 404 Tidak Ditemukan.

Benar-benar orang yang sederhana. Ini bukan ilmu roket. Ada hubungan absolut antara bagian path / file dari URL dan sistem file.

1. URL mengklaim sebagai pencari sumber daya UNIFORM dan dapat menunjuk ke sumber daya yang ada sebelum web. Beberapa di antaranya peka huruf besar-kecil (misalnya banyak server ftp) dan URL harus dapat mewakili sumber daya ini dengan cara yang cukup intuitif.

2. Ketidakpekaan case membutuhkan lebih banyak pekerjaan ketika mencari kecocokan (baik di OS atau di atasnya).

3. Jika Anda mendefinisikan URL sebagai server individual yang peka terhadap huruf besar, dapat menerapkannya sebagai tidak peka huruf besar-kecil jika mereka mau. Kebalikannya tidak benar.

4. Ketidakpekaan case bisa non-sepele dalam konteks internasional: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Juga RFC1738 diizinkan untuk penggunaan karakter di luar rentang ASCII asalkan mereka dikodekan tetapi tidak menentukan charset. Ini cukup penting untuk sesuatu yang menamakan dirinya web luas DUNIA. Menentukan URL sebagai tidak peka huruf besar-kecil akan membuka banyak ruang untuk bug.

5. Jika Anda mencoba mengemas banyak data ke dalam URI (mis. Data URI ), Anda dapat mengemas lebih banyak jika huruf besar dan kecil berbeda.

Saya mencuri dari blog New Old Thing kebiasaan mendekati pertanyaan dari bentuk "mengapa ada sesuatu yang terjadi?" dengan pertanyaan tandingan "seperti apa dunia ini, jika bukan itu masalahnya?"

Katakanlah saya mengatur server web untuk melayani sendiri file dokumen saya dari folder sehingga saya bisa membacanya di telepon ketika saya berada di luar kantor. Sekarang, di folder dokumen saya, saya memiliki tiga file, todo.txt, ToDo.txtdan TODO.TXT(aku tahu, tapi itu masuk akal untuk saya ketika saya membuat file).

URL apa yang ingin saya gunakan, untuk mengakses file-file ini? Saya ingin mengaksesnya secara intuitif, menggunakan http://www.example.com/docs/filename.

Katakanlah saya memiliki skrip yang memungkinkan saya menambahkan kontak ke buku alamat saya, yang juga dapat saya lakukan melalui web. Bagaimana seharusnya mengambil parameternya? Nah, saya ingin menggunakannya seperti: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Tetapi jika tidak ada cara bagi saya untuk menentukan nama berdasarkan kasus, bagaimana saya melakukannya?

Bagaimana saya membedakan halaman wiki untuk Kucing dan CAT, Teks dan TEKS, lateks dan LaTeX? Halaman disambig, saya kira, tapi saya lebih suka hanya mendapatkan hal yang saya minta.

Tapi semua itu terasa seperti menjawab pertanyaan yang salah.

Pertanyaan saya pikir Anda benar-benar bertanya adalah "Mengapa server web 404 Anda hanya untuk perbedaan kasus, ketika mereka komputer, dirancang untuk membuat hidup lebih sederhana, dan mereka sangat mampu menemukan setidaknya variasi kasus yang paling jelas dalam URL yang saya ketikkan itu akan berfungsi? "

Jawabannya adalah bahwa sementara beberapa situs telah melakukan ini (dan lebih baik, mereka memeriksa kesalahan ketik lainnya juga), tidak ada yang berpikir itu berguna untuk mengubah halaman kesalahan 404 default webserver untuk melakukan itu ... tapi mungkin mereka harus melakukannya?

Padahal jawaban di atas sudah benar & bagus. Saya ingin menambahkan beberapa poin lagi.

Untuk memahami lebih baik, Anda harus memahami perbedaan mendasar antara server Unix (Linux) Vs Windows. Unix peka huruf besar kecil & Windows bukan huruf besar-kecil.

Protokol HTTP dikembangkan atau mulai diterapkan sekitar tahun 1990. Protokol HTTP dirancang oleh insinyur yang bekerja di lembaga CERN, sebagian besar ilmuwan menggunakan mesin Unix dan bukan Windows.

Sebagian besar ilmuwan akrab dengan Unix, sehingga mereka mungkin telah dipengaruhi oleh sistem file gaya Unix.

Windows server dirilis setelah tahun 2000. jauh sebelum windows server menjadi protokol HTTP populer telah matang dan spesifikasi selesai.

Ini bisa menjadi alasannya.

Bagaimana seharusnya orang membaca "mengapa itu dirancang seperti ini?" pertanyaan? Apakah Anda meminta akun yang secara historis akurat tentang proses pengambilan keputusan, atau apakah Anda bertanya "mengapa ada orang yang merancang seperti ini?"?

Sangat jarang memungkinkan untuk mendapatkan akun yang akurat secara historis. Kadang-kadang ketika keputusan dibuat dalam komite standar ada jejak dokumenter tentang bagaimana perdebatan dilakukan, tetapi pada hari-hari awal keputusan web dibuat dengan tergesa-gesa oleh beberapa individu - dalam hal ini mungkin oleh TimBL sendiri - dan alasannya tidak mungkin telah ditulis. Tetapi TimBL telah mengakui bahwa ia membuat kesalahan dalam desain URL - lihat http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

Pada hari-hari awal, URL dipetakan sangat langsung ke nama file, dan file-file tersebut umumnya pada mesin seperti Unix, dan mesin seperti Unix memiliki nama file sensitif. Jadi dugaan saya adalah bahwa kebetulan saja untuk kenyamanan implementasi, dan kegunaan (untuk pengguna akhir) bahkan tidak pernah dipertimbangkan. Lagi-lagi, pada hari-hari awal para pengguna adalah semua programmer Unix.

Ini tidak ada hubungannya dengan tempat Anda membeli domain Anda, DNS tidak peka huruf besar-kecil. Tapi, sistem file di server yang Anda gunakan untuk hosting adalah.

Ini sebenarnya bukan masalah dan cukup umum di * nix hosts. Pastikan semua tautan yang Anda tulis di halaman sudah benar dan Anda tidak akan mengalami masalah. Untuk membuatnya lebih mudah, saya sarankan selalu memberi nama halaman Anda dalam huruf kecil semua maka Anda tidak perlu memeriksa nama saat menulis tautan.

Closetnoc benar tentang OS. Beberapa sistem file memperlakukan nama yang sama dengan casing yang berbeda dengan file yang berbeda.

Juga, adakah tujuan / keuntungan nyata untuk memiliki URL peka huruf besar-kecil (yang bertentangan dengan sebagian besar URL yang mengarah ke halaman yang sama tidak peduli kapitalisasi)?

Iya. untuk menghindari masalah duplikat konten.

Misalnya Anda memiliki URL berikut:

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

dan mereka semua menunjuk ke halaman yang sama persis dengan konten yang sama persis, maka Anda akan memiliki duplikat konten, dan saya yakin jika Anda memiliki akun konsol pencarian Google (alat webmaster), Google akan menunjukkan ini kepada Anda.

Apa yang saya sarankan lakukan jika Anda berada dalam situasi itu adalah dengan menggunakan semua URL huruf kecil, kemudian mengarahkan URL dengan setidaknya satu huruf kapital di dalamnya ke versi huruf kecil. Jadi dalam daftar URL di atas, arahkan semua URL ke URL pertama.

Sensitivitas kasus memang memiliki nilai.

Jika ada 26 huruf, masing-masing dengan kapitalisasi, itu 52 karakter.

4 karakter memiliki kemungkinan kombinasi 52 * 52 * 52 * 52, sama dengan 7311616 kombinasi.

Jika Anda tidak dapat menggunakan huruf besar untuk karakter, jumlah kombinasi adalah 26 * 26 * 26 * 26 = 456976

Kombinasi lebih dari 14 kali lebih banyak untuk 52 karakter daripada untuk 26 karakter. Jadi untuk menyimpan data, Url bisa lebih pendek dan lebih banyak informasi dapat dilewatkan melalui jaringan dengan lebih sedikit data yang ditransfer.

Inilah sebabnya mengapa Anda melihat YouTube menggunakan URL seperti https://www.youtube.com/watch?v=xXxxXxxX