Почему URL чувствительны к регистру?

Мой вопрос: когда URL были впервые разработаны, почему чувствительность к регистру стала функцией? Я спрашиваю об этом, потому что мне (т.е. непрофессионалу) кажется, что нечувствительность к регистру предпочтительнее, чтобы предотвратить ненужные ошибки и упростить и без того сложную строку текста.

Кроме того, есть ли реальная цель / преимущество в том, чтобы иметь чувствительный к регистру URL (в отличие от подавляющего большинства URL, которые указывают на одну и ту же страницу независимо от ее заглавных букв)?

Википедия, например, является веб-сайтом, чувствительным к регистру букв (за исключением первого символа):

https://en.wikipedia.org/wiki/St ck_Exchange является ДОА.

Почему 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/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAIBAKAAGAGAGAGAGAGAAAAAAAAAAAAAAAAAjAjA
• Сокращения URL-адресов используют чувствительность к регистру: /a5Bможет отличаться от/a5b
• Как вы упомянули, Википедия может отличать «СПИД» от «СПИДа».

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

[Обновить]

В комментариях было несколько веских аргументов (так как они были удалены) о том, имеют ли URL какие-либо связи с файловой системой, как я уже говорил. Эти аргументы стали горячими. Чрезвычайно близоруко полагать, что нет никаких отношений. Там абсолютно есть! Позвольте мне объяснить дальше.

Программисты приложений обычно не являются системными программистами. Я не оскорбляю. Это две отдельные дисциплины, и знание внутренних систем не требуется для написания приложений, когда приложения могут просто совершать вызовы в ОС. Поскольку прикладные программисты не являются системными программистами, обход сервисов ОС невозможен. Я говорю это потому, что это два отдельных лагеря, и они редко пересекаются. Приложения пишутся для использования сервисов ОС как правило. Конечно, есть редкие исключения.

Когда веб-серверы начали появляться, разработчики приложений не пытались обойти службы ОС. Для этого было несколько причин. Во-первых, это было не нужно. Во-вторых, прикладные программисты, как правило, не знали, как обойти службы ОС. В-третьих, большинство ОС были либо чрезвычайно стабильными и надежными, либо чрезвычайно простыми и легкими и не стоили затрат.

Имейте в виду, что ранние веб-серверы либо работали на дорогих компьютерах, таких как серверы DEC VAX / VMS и Unix-системы того времени (Беркли и Ультрикс, а также другие), на компьютерах с основным или средним кадром, а затем вскоре после легкие компьютеры, такие как ПК и 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. Но если бы у меня не было возможности указать имя в каждом конкретном случае, как бы я это сделал?

Как бы я дифференцировал вики-страницы для Cat и CAT, Text и TEXT, латекса и LaTeX? Наверное, я устраню неоднозначность страниц, но предпочитаю просто получить то, о чем просил.

Но все равно кажется, что он отвечает на неправильный вопрос.

Вопрос, который, я думаю, вы действительно задавали, заключается в следующем: «Почему веб-серверы 404 вас просто интересуют, если они представляют собой компьютеры, призванные упростить жизнь, и они вполне способны найти, по крайней мере, наиболее очевидные варианты вариантов в URL, который я набрал, будет работать?

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

Хотя приведенный выше ответ является правильным и хорошим. Я хотел бы добавить еще несколько пунктов.

Чтобы лучше понять, нужно понимать принципиальную разницу между Unix (Linux) и Windows сервером. 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-admits-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-адреса на первый URL-адрес.

Чувствительность к регистру имеет значение.

Если есть 26 букв, каждая из которых имеет заглавные буквы, то это 52 символа.

4 символа имеют возможность комбинации 52 * 52 * 52 * 52, что равно 7311616 комбинациям.

Если вы не можете использовать заглавные буквы, количество комбинаций составляет 26 * 26 * 26 * 26 = 456976

Комбинаций для 52 символов более чем в 14 раз больше, чем для 26. Таким образом, для хранения данных URL-адреса могут быть короче, и по сети может передаваться больше информации с меньшим количеством передаваемых данных.

Вот почему вы видите YouTube, используя URL-адреса, такие как https://www.youtube.com/watch?v=xXxxXxxX