Чому URL-адреси залежать від регістру?

Моє запитання: Коли вперше були розроблені URL-адреси, чому функція чутливості до регістру стала функцією? Я запитую це, тому що мені здається (наприклад, лайперсону), що нечутливість до випадку буде кращою для запобігання непотрібних помилок та спрощення і без того складного рядка тексту.

Також, чи є реальна мета / перевага мати URL-адресу, що відрізняється від регістру (на відміну від переважної більшості URL-адрес, які вказують на одну і ту ж сторінку, незалежно від великої літери)?

Наприклад, Вікіпедія - це веб-сайт, який чутливий до букви букв (крім першого символу):

https://en.wikipedia.org/wiki/St A ck_Exchange - DOA.

Чому б URL-адреса не була чутливою до регістру?

Я розумію, що це може виглядати як провокаційний (і "захисник диявола") риторичного питання, але я думаю, що це корисно розглянути. Конструкція HTTP полягає в тому, що "клієнт", якого ми зазвичай називаємо "веб-браузером", запитує дані "веб-сервера".

Випускається багато, багато різних веб-серверів. Microsoft випустила IIS з операційними системами Windows Server (та іншими, включаючи Windows XP Professional). У Unix є важкі ваги, такі як nginx та Apache, не кажучи вже про менші пропозиції, такі як внутрішній httpd OpenBSD, або thttpd, або lighttpd. Крім того, багато мережевих пристроїв мають вбудовані веб-сервери, які можна використовувати для налаштування пристрою, включаючи пристрої з цілями, характерними для мереж, як маршрутизатори (включаючи безліч точок доступу Wi-Fi та модеми DSL) та інші пристрої, такі як принтери або ДБЖ (акумуляторні батареї безперебійного живлення), які можуть мати мережеве підключення.

Тож питання "Чому URL-адреси залежать від регістру?", Запитує: "Чому веб-сервери ставляться до URL як до регістру?" І власне відповідь така: вони не всі так роблять. Принаймні один веб-сервер, який є досить популярним, як правило, НЕ чутливий до регістру. (Веб-сервер - IIS.)

Основна причина різної поведінки між різними веб-серверами, ймовірно, зводиться до простоти. Найпростіший спосіб зробити веб-сервер - це робити так само, як операційна система комп'ютера / пристрою розміщує файли. Багато разів веб-сервери знаходять файл, щоб надати відповідь. Unix був розроблений навколо комп'ютерів вищого класу, і тому Unix забезпечив бажану функціональність, дозволяючи великі та малі літери. Unix вирішив розглядати великі і малі регістри як різні, тому що, ну, вони різні. Це прямо, природно. Windows має історію нечутливості до регістру через бажання підтримувати вже створене програмне забезпечення, і ця історія повертається до DOS, який просто не підтримував малі літери, можливо, намагаючись спростити речі з менш потужними комп’ютерами, які використовують менше пам’яті. Оскільки ці операційні системи різні, результат полягає в тому, що просто розроблені (ранні версії) веб-сервери відображають однакові відмінності.

Тепер, з урахуванням цього досвіду, ось деякі конкретні відповіді на конкретні питання:

Коли вперше були розроблені URL-адреси, чому саме чутливість до регістру стала функцією?

Чому ні? Якщо всі стандартні веб-сервери не залежать від регістру, це вказує на те, що веб-сервери дотримуються набору правил, визначених стандартом. Просто не було правила, яке говорить про те, що цю справу потрібно ігнорувати. Причиною відсутності правила є просто те, що не було причини існування такого правила. Навіщо турбуватися складати непотрібні правила?

Я запитую це, тому що мені здається (наприклад, лайперсону), що нечутливість до випадку буде кращою для запобігання непотрібних помилок та спрощення і без того складного рядка тексту.

URL-адреси були розроблені для обробки машин. Хоча людина може ввести повну URL-адресу в адресний рядок, це не було основною частиною задуманого дизайну. Задумана конструкція полягає в тому, щоб люди дотримувались ("натискання на") гіперпосилань. Якщо це роблять середньостатистичні люди, то їм насправді все одно, чи невидима URL-адреса проста чи складна.

Також, чи є реальна мета / перевага мати URL-адресу, що відрізняється від регістру (на відміну від переважної більшості URL-адрес, які вказують на одну і ту ж сторінку, незалежно від великої літери)?

У п'ятій нумерованій точці відповіді Вільяма Хей згадується одна технічна перевага: URL-адреси можуть бути ефективним способом для веб-браузера надсилати трохи інформації на веб-сервер, і більше інформації може бути включена, якщо є менше обмежень, тому чутливість до справи обмеження зменшило б кількість інформації, яка може бути включена.

Однак у багатьох випадках не існує надто переконливої ​​переваги щодо чутливості регістру, що підтверджується тим, що IIS зазвичай не турбується.

Підсумовуючи це, найбільш переконливою причиною є, мабуть, простота для тих, хто розробляв програмне забезпечення веб-сервера, особливо на платформі, що враховує регістр, як Unix. (HTTP не був чимось, що вплинуло на оригінальний дизайн Unix, оскільки Unix помітно старший ніж HTTP.)

URL-адреси не відрізняються від регістру, лише їх частини.
Наприклад, в URL-адресі нічого не залежить від регістру https://google.com,

З посиланням на RFC 3986 - Уніфікований ідентифікатор ресурсу (URI): Загальний синтаксис

По-перше, з Вікіпедії URL виглядає так:

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

(Я видалив user:passwordдеталь, тому що вона не цікава і рідко використовується)

• scheme:

схеми нечутливі до регістру

• host:

Хост-підкомпонент нечутливий до регістру.

• path:

Компонент шляху містить дані ...

• query:

Компонент запиту містить неієрархічні дані ...

• fragment:

Окремі типи медіа можуть визначати власні обмеження на або структури в синтаксисі ідентифікатора фрагмента для вказівки різних типів підмножин, переглядів чи зовнішніх посилань

Отже, schemeі hostє нечутливими до регістру.
Решта URL-адреси залежить від регістру.

Чому pathзалежно від регістру?

Це, здається, головне питання.
Важко відповісти "чому" щось було зроблено, якщо це не було задокументовано, але ми можемо дуже гарно здогадатися.
Я вибрав із специфікації дуже конкретні цитати з акцентом на дані .
Давайте ще раз розглянемо URL-адресу:

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

• Розташування - місцеположення має канонічну форму та нечутливе до регістру. Чому? Можливо, ви можете придбати доменне ім’я, не купуючи тисячі варіантів.

• Дані - дані використовуються цільовим сервером, і програма може вибрати, що це означає . Не було б сенсу робити обробку даних нечутливою. У додатку повинно бути більше варіантів, і визначення нечутливості випадків у специфікації обмежить ці параметри.
  Це також корисна відмінність для HTTPS: дані шифруються , але хост видно.

Це корисно?

Чутливість до регістру має свої підводні камені, коли мова йде про кешування та канонічні URL-адреси, але це, безумовно, корисно. Деякі приклади:

• Base64 , який використовується в URI даних .
• Сайти можуть кодувати дані Base64 у URL-адресі, наприклад: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAAACAACAACAACAACAACAACAACAACAACAACAACAACAACA
• Скорочувачі URL-адрес використовують чутливість до регістру: /a5Bможуть бути різними, ніж/a5b
• Як ви вже згадували, Вікіпедія може відрізняти "СНІД" від "СНІДу".

Простий. В ОС залежно від регістру. Веб-сервери, як правило, не хвилюються, якщо їм не доведеться в якийсь момент потрапити на файлову систему Ось де Linux та інші операційні системи на базі Unix застосовують правила файлової системи, у цьому випадку чутливість є основною частиною. Ось чому IIS ніколи не враховував регістри; тому що Windows ніколи не враховував регістри.

[Оновлення]

У коментарях (з моменту видалення) в аргументах (із видаленими) були деякі вагомі аргументи щодо того, чи URL-адреси мають відношення до файлової системи, як я вже зазначив. Ці аргументи стали гарячими. Вкрай недалекоглядно вважати, що стосунків немає. Там абсолютно є! Дозвольте пояснити далі.

Прикладні програмісти, як правило, не є внутрішніми програмістами. Мене не ображають. Вони є двома окремими дисциплінами, і знання внутрішніх систем не потрібно для написання додатків, коли програми можуть просто телефонувати в ОС. Оскільки прикладні програмісти не є внутрішніми програмістами, обхід служб ОС неможливий. Я говорю це тому, що це два окремих табори, і вони рідко перетинаються. Програми пишуться як правило для використання служб ОС. Звичайно, є рідкісні винятки.

Ще коли веб-сервери почали з’являтися, розробники додатків не намагалися обійти служби ОС. Причин для цього було кілька. Один, не треба було. По-друге, програмісти програм зазвичай не знали, як обійти служби ОС. Три, більшість ОС були або надзвичайно стабільними і надійними, або надзвичайно простими і легкими, і не варті витрат.

Майте на увазі, що ранні веб-сервери або працювали на дорогих комп'ютерах, таких як DEC VAX / VMS-сервери та Unix дня (Berkeley і Ultrix, а також інші) на комп'ютерах з основним або середнім кадром, а потім незабаром на легкі комп'ютери, такі як ПК та Windows 3.1. Коли почали з'являтися більш сучасні пошукові системи, такі як Google в 1997/8, Windows перейшла в Windows NT, а інші ОС, такі як Novell і Linux, також почали запускати веб-сервери. Apache був домінуючим веб-сервером, хоча існували й інші, такі як IIS та O'Reilly, які також були дуже популярні. Жоден з них на той час не обійшов служби ОС. Ймовірно, що жоден із веб-серверів не робить навіть сьогодні.

Ранні веб-сервери були досить простими. Вони є і сьогодні. Будь-який запит, зроблений для ресурсу через HTTP-запит, який існує на жорсткому диску, був / робиться веб-сервером через файлову систему ОС.

Файлові системи - це досить прості механізми. Оскільки робиться запит на доступ до файлу, якщо такий файл існує, запит передається в підсистему авторизації, і якщо надано, оригінальний запит задовольняється. Якщо ресурс не існує або не дозволений, система викидає виняток. Коли програма робить запит, встановлюється тригер і програма чекає. Коли відповідь на запит запускається тригер і програма обробляє відповідь на запит. Це працює і сьогодні. Якщо програма бачить, що запит був задоволений, він продовжується, якщо його не вдалося, програма виконує умову помилки в межах свого коду або відмирає, якщо не обробляється. Простий.

У випадку веб-сервера, якщо припустити, що зроблено запит URL для шляху / файлу, веб-сервер приймає частину шляху / файлу URL-запиту (URI) та робить запит до файлової системи, і він або задоволений або кидає виняток. Потім веб-сервер обробляє відповідь. Наприклад, якщо запитуваний шлях та файл знайдені та доступ надається підсистемою авторизації, то веб-сервер обробляє запит вводу / виводу як звичайний. Якщо файлова система кидає виняток, веб-сервер повертає помилку 404, якщо файл не знайдено або 403 заборонено, якщо код причини несанкціонований.

Оскільки деякі ОС відрізняються від регістру і файлові системи цього типу вимагають точних відповідностей, шлях / файл, який вимагається веб-сервером, повинен точно відповідати тому, що існує на жорсткому диску. Причина цього проста. Веб-сервери не здогадуються, що ви маєте на увазі. Жоден комп’ютер не робить цього без запрограмованого. Веб-сервери просто обробляють запити під час їх отримання. Якщо частина шляху / файлу URL-запиту, що передається безпосередньо до файлової системи, не відповідає тому, що знаходиться на жорсткому диску, тоді файлова система видає виняток, і веб-сервер повертає помилку 404 Not Found.

Це дійсно прості люди. Це не ракетна наука. Існує абсолютна залежність між частиною шляху / файлу URL-адреси та файловою системою.

1. URL-адреси претендують на пошук ресурсів UNIFORM і можуть вказувати на ресурси, що передували Інтернету. Деякі з них залежать від регістру (наприклад, багато ftp-серверів), і URL-адреси повинні бути в змозі представляти ці ресурси досить інтуїтивно.

2. Нечутливість випадку вимагає більше роботи при пошуку відповідності (або в ОС, або над нею).

3. Якщо ви визначите URL-адреси як регістри, то окремі сервери можуть їх реалізувати як нечутливі до регістру, якщо вони хочуть. Зворотний неправда.

4. Нечутливість випадків може бути нетривіальною у міжнародних контекстах: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Також RFC1738 дозволяв використовувати символи поза діапазоном ASCII за умови, що вони були закодовані, але не вказали діаграму. Це досить важливо для чогось, що називає себе СВІТОМ. Визначення URL-адрес як нечутливих до регістру відкрило б багато можливостей для помилок.

5. Якщо ви намагаєтесь запакувати багато даних в URI (наприклад, URI даних ), ви можете спакувати більше, якщо верхній і нижній регістри відрізняються.

Я вкрав у блогу стару Нову річ звичку підходити до питань форми "чому це щось так?" із зустрічним запитанням "яким би був світ, якби не так?"

Скажіть, я створив веб-сервер для обслуговування своїх файлів документів із папки, щоб я міг їх читати по телефону, коли я був поза офісом. Тепер в моїй папці документів, у мене є три файли, todo.txt, ToDo.txtі TODO.TXT(я знаю, але це має сенс для мене , коли я зробив файли).

Яку URL-адресу я хотів би використовувати, щоб отримати доступ до цих файлів? Я хотів би отримати доступ до них інтуїтивно зрозумілим способом http://www.example.com/docs/filename.

Скажімо, у мене є сценарій, який дозволяє мені додати контакт до моєї адресної книги, що я також можу зробити через Інтернет. Як це має приймати його параметри? Ну, я хотів би використовувати його як: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Але якби мені не вдалося вказати ім’я в кожному випадку, як би я це зробив?

Як я можу розмежувати сторінки wiki для Cat та CAT, Text та TEXT, латексу та LaTeX? Думаю, розібрані сторінки, але я вважаю за краще отримати те, про що я попросив.

Але все, що відчуває, ніби відповідає на неправильне запитання.

Питання, яке, на мою думку, ви насправді задавали: "Чому веб-сервери 404 вам просто для різниці випадків, коли вони є комп'ютерами, розробленими для того, щоб зробити життя простішим, і вони цілком здатні знайти хоча б найочевидніші варіації випадків у URL-адресу, яку я набрав, яка буде працювати? "

Відповідь на це полягає в тому, що, хоча деякі сайти робили це (а ще краще, вони перевіряють інші помилки), ніхто не думав, що варто змінити сторінку помилки 404 веб-сервера за замовчуванням, щоб це зробити ... але, можливо, вони повинні?

Хоча вищевказана відповідь правильна і хороша. Я хотів би додати ще кілька балів.

Щоб краще зрозуміти, слід зрозуміти основну різницю між сервером Windows Unix (Linux) Vs. Unix відрізняється від регістру, а Windows - нечутливою до регістру ОС.

Протокол HTTP був розроблений або почав впроваджуватися близько 1990 року. Протокол HTTP був розроблений інженерами, що працюють в інститутах CERN, більшість тих днів вчений використовував машини Unix, а не Windows.

Більшість вчених були знайомі з Unix, тому на них може вплинути файлова система стилю Unix.

Сервер Windows був випущений після 2000 р. Набагато до того, як Windows сервер став популярним протокол HTTP був добре дозрілий і специфікація завершена.

Це може бути причиною.

Як слід читати "чому це було розроблено таким чином?" питання? Ви запитуєте історично точний виклад процесу прийняття рішень, або ви запитуєте "чому хтось спроектував би це так?"

Дуже рідко можливо отримати історично точний рахунок. Іноді, коли рішення приймаються в комітетах зі стандартів, є документальний слід про те, як проводилися дебати, але в перші дні веб-рішень було прийнято поспішно декількома особами - у цьому випадку, мабуть, самим TimBL - і обґрунтування малоймовірне. щоб були записані. Але TimBL визнав, що припустився помилок при розробці URL-адрес - див. Http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admit-forward-slashes-web-address -mistake.html

У перші дні URL-адреси відображалися дуже безпосередньо до імен файлів файлів, і файли, як правило, були на Unix-подібних машинах, а Unix-подібні машини мають чутливі до регістру імена файлів. Тож я здогадуюсь, що саме так сталося для зручності впровадження, а зручність використання (для кінцевих споживачів) навіть не розглядалася. Знову ж таки, в перші дні користувачі все одно були програмістами Unix.

Це не має нічого спільного з тим, де ви купили свій домен, DNS не враховує регістри. Але файлова система на сервері, який ви використовуєте для хостингу, є.

Це насправді не проблема, і вона досить поширена на хостах * nix. Просто переконайтесь, що всі посилання, які ви пишете на своїх сторінках, є правильними, і у вас не виникне проблем. Для того, щоб було простіше, я рекомендую завжди називати ваші сторінки в усіх малих літерах, тоді вам ніколи не потрібно двічі перевіряти ім'я під час написання посилання.

Closetnoc має рацію щодо ОС. Деякі файлові системи трактують одне і те ж ім’я з різним корпусом як різні файли.

Також, чи є реальна мета / перевага мати URL-адресу, що відрізняється від регістру (на відміну від переважної більшості URL-адрес, які вказують на одну і ту ж сторінку, незалежно від великої літери)?

Так. щоб уникнути повторюваних проблем із вмістом.

Якщо у вас були, наприклад, такі URL-адреси:

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

і всі вони вказували на ту саму сторінку з точно однаковим вмістом, тоді ви мали б повторюваний вміст, і я впевнений, що якщо у вас є обліковий запис пошукової консолі Google (інструменти для веб-майстрів), Google вкаже вам це.

Я б запропонував зробити, якщо ви знаходитесь у цій ситуації, - це використовувати всі малі регістри, а потім перенаправити URL-адреси, що містять хоча б одну велику літеру, на малу версію. Тож у списку URL-адрес, наведених вище, перенаправляйте всі URL-адреси до першої URL-адреси.

Чутливість до справ має значення.

Якщо є 26 літер, кожна з яких має змогу використовувати великі літери, це 52 символи.

4 символи мають можливість комбінацій 52 * 52 * 52 * 52, що дорівнює 7311616 комбінацій.

Якщо ви не можете використовувати великі літери, кількість комбінацій становить 26 * 26 * 26 * 26 = 456976

У 52 рази більше комбінацій на 52 символи, ніж у 26. Отже, для зберігання даних URL-адреси можуть бути коротшими і більше інформації можна передавати по мережах з меншою кількістю переданих даних.

Ось чому ви бачите YouTube, використовуючи такі URL-адреси, як https://www.youtube.com/watch?v=xXxxXxxX