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

54

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

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

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

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

рукав моря
источник
11
Вы, очевидно, не запускаете IIS в Windows
Джон Конде
53
Я полагаю, что itscrap.com, expertsexchange и whorepresents.com предпочли бы, чтобы больше людей использовали имена с учетом регистра. Для получения дополнительной информации см. Boredpanda.com/worst-domain-names .
Эрик Тауэрс
22
URL были разработаны, когда динозавры, отображаемые в системах Unix, бродили по Земле, а Unix чувствителен к регистру.
Торбьерн Равн Андерсен
11
Википедия пытается использовать правильную заглавную букву для названия темы и использует перенаправления для общих различий. например. html, htmИ Htmlвесь редирект HTML. Но важно то, что из-за огромной тематики, возможно иметь более одной страницы, где URL отличается только в зависимости от конкретного случая. Например: Латекс и LaTeX
MrWhite
7
@ edc65 Но Kobi утверждает , что части этого URL ( в частности пути ) являются чувствительны к регистру - так, что не делает URL (в целом) с учетом регистра?
MrWhite

Ответы:

8

Почему 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.)

TOOGAM
источник
«Основная причина различного поведения разных браузеров, вероятно, сводится к простоте». - Я предполагаю, что вы имеете в виду «веб-серверы», а не «веб-браузеры» здесь и в нескольких других местах?
MrWhite
2
Обновлено. Пересмотрел каждый случай «браузеров» и сделал несколько замен. Спасибо, что указали на это, чтобы можно было улучшить качество.
TOOGAM
1
Я получил несколько отличных ответов на мой вопрос, от исторического до технического. Я не решаюсь пойти против и принять более низкий рейтинг, но ответ @ TOOGAM был для меня самым полезным. Этот ответ является исчерпывающим и всеобъемлющим, но он объясняет концепцию несложным, разговорным способом, который я могу понять. И я думаю, что этот ответ является хорошим введением в более глубокие объяснения.
Кайл
74

URL не чувствительны к регистру, только их части.
Например, ничто не чувствительно к регистру в URL https://google.com,

Со ссылкой на RFC 3986 - Унифицированный идентификатор ресурса (URI): общий синтаксис

Во-первых, из Википедии URL выглядит так:

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

(Я удалил user:passwordчасть, потому что она не интересна и редко используется)

схемы нечувствительны к регистру

Подкомпонент хоста не учитывает регистр.

Компонент пути содержит данные ...

Компонент запроса содержит неиерархические данные ...

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

Таким образом, schemeи hostбез учета регистра.
Остальная часть URL чувствительна к регистру.

Почему pathрегистр чувствителен?

Это, кажется, главный вопрос.
Трудно ответить «почему» что-то было сделано, если это не было задокументировано, но мы можем сделать очень хорошее предположение.
Я выбрал очень конкретные цитаты из спецификации, с акцентом на данные .
Давайте снова посмотрим на URL:

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data
  • Местоположение - Местоположение имеет каноническую форму и нечувствительно к регистру. Почему? Вероятно, чтобы вы могли купить доменное имя без необходимости покупать тысячи вариантов.

  • Данные - данные используются целевым сервером, и приложение может выбирать, что это значит . Было бы бессмысленно делать данные нечувствительными к регистру. Приложение должно иметь больше параметров, и определение нечувствительности к регистру в спецификации ограничит эти параметры.
    Это также является полезным отличием для HTTPS: данные зашифрованы , но хост виден.

Это полезно?

Чувствительность к регистру имеет свои подводные камни, когда речь идет о кэшировании и канонических URL, но это, безусловно, полезно. Некоторые примеры:

Коби
источник
1
«URL не чувствительны к регистру.» / "Остальная часть URL чувствительна к регистру." - Это может показаться противоречием?
MrWhite
8
По правде говоря, схема определяет, чего ожидать в оставшейся части URL. http:и связанные схемы означают, что URL относится к имени хоста DNS. DNS был ASCII без учета регистра задолго до изобретения URL. См. Стр. 55 ietf.org/rfc/rfc883.txt
О. Джонс
3
Красиво подробно! Я шел с исторической точки зрения. Первоначально это был путь к файлу, который требовал учета регистра только в том случае, если вы работали с файловой системой. Иначе этого не было. Но сегодня все изменилось. Например, параметры и CGI изначально не существовали. Ваш ответ принимает текущую перспективу дня. Я должен был вознаградить ваши усилия !! Вы действительно копались в этом! Кто знал, что это взорвет, как это было ?? Ура !!
closetnoc
2
@ w3dk: это не очень интересная причуда терминологии, но вы могли бы принять «чувствительный к регистру», чтобы означать, «изменение регистра символа может изменить целое», или вы могли бы принять это как «изменение регистр персонажа всегда меняет целое ". Коби, кажется, утверждает последнее, он предпочитает, чтобы чувствительность к регистру означала «любое изменение в случае значительного», что, конечно, не относится к URL-адресам. Вы предпочитаете первое. Вопрос только в том, насколько они чувствительны к делу.
Стив Джессоп
2
@ rybo111: Если пользователь вводит example.com/fOObaR , спецификация требует, чтобы сервер на www.example.com получил путь "/ fOObaR", как указано; в нем ничего не говорится о том, должен ли сервер относиться к этому как-то иначе, чем "/ foOBaR".
суперкат
59

Просто. ОС чувствительна к регистру. Веб-серверам, как правило, все равно, если только они не попадут в файловую систему. Именно здесь 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-адреса и файловой системой.

closetnoc
источник
1
Я думаю, что ваш аргумент неверен. В то время как у Бернерса-Ли не было никакого выбора относительно чувствительности к регистру ftp URL. Он получил дизайн http URL. Он мог указать их только как US-ASCII и без учета регистра. Если когда-либо существовали какие-либо веб-серверы, которые просто передавали URL-путь к файловой системе, они были небезопасны, и введение кодировки URL нарушало их совместимость. Учитывая, что путь обрабатывается перед передачей в дело об уничтожении ОС, было бы легко реализовать. Поэтому я думаю, что мы должны рассматривать это как проектное решение, а не как причину реализации.
Уильям Хэй,
@WilliamHay Это не имеет ничего общего с Бернерс-Ли или дизайном сети. Речь идет об ограничениях и требованиях ОС. Я бывший системный инженер. Я работал над этими системами в то время. Я говорю вам точно, почему URL чувствительны к регистру. Это не догадка. Это не мнение. Это факт. Мой ответ был намеренно упрощен. Конечно, существуют проверки файлов и другие процессы, которые можно выполнить перед выполнением любого открытого оператора. И да (!) Веб-серверы частично небезопасны и по сей день в результате.
closetnoc
Являются ли URL-адреса чувствительными к регистру, не имеет ничего общего с дизайном сети? В самом деле? Аргумент от Власти, сопровождаемый Аргументом Утверждение. То, что веб-серверы передают компонент пути URL-адреса более или менее непосредственно на открытый вызов, является следствием дизайна URL-адресов, а не его причиной. Серверы (или умные клиенты в случае FTP) могли скрыть чувствительность к регистру файловых систем от пользователя. То, что они этого не делают, является дизайнерским решением.
Уильям Хэй
@WilliamHay Вам нужно замедлить бункер для травы и перечитать то, что я написал. Я - системный инженер на пенсии, пишу компоненты ОС, стеки протоколов и код маршрутизатора для ARPA-Net и т. Д. Я работал с Apache, O'Reilly и IIS. Ваш аргумент FTP не содержит воды, так как по крайней мере основные серверы FTP остаются чувствительными к регистру по той же причине. Ни разу я ничего не говорил о дизайне URL / URI. Я никогда не говорил, что веб-серверы передают значения без обработки. Я говорил, что службы ОС обычно используются и что файловая система требует точного соответствия для успеха.
closetnoc
@WilliamHay Пожалуйста, поймите, что мы с вами думаем о разных целях. Все, что я сказал в своем ответе, - это то, что для некоторых ОС вызовы файловой системы учитывают регистр символов. Приложения, которые используют системные вызовы, и большинство из них, ограничены применением правил ОС - в этом случае чувствительность к регистру. Это не невозможно обойти это правило. На самом деле это может быть несколько тривиально в некоторых случаях, но не практично. В своей работе я обычно обходил файловую систему, чтобы расшифровывать жесткие диски, которые по той или иной причине пошли в kablooie, или анализировать внутренние файлы файлов и т. Д.
closetnoc
21
  1. URL-адреса утверждают, что они являются локатором ресурсов UNIFORM и могут указывать на ресурсы, предшествующие сети. Некоторые из них чувствительны к регистру (например, многие FTP-серверы), и URL-адреса должны быть в состоянии представить эти ресурсы достаточно интуитивно понятным способом.

  2. Нечувствительность к регистру требует больше работы при поиске совпадения (либо в ОС, либо над ней).

  3. Если вы определяете URL-адреса как чувствительные к регистру, отдельные серверы могут реализовать их без учета регистра, если они этого хотят. Обратное неверно.

  4. Нечувствительность к регистру может быть нетривиальной в международном контексте: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Также RFC1738 допускает использование символов вне диапазона ASCII, если они закодированы, но не указывают кодировку. Это довольно важно для того, кто называет себя всемирной паутиной. Определение URL как нечувствительного к регистру откроет много возможностей для ошибок.

  5. Если вы пытаетесь упаковать много данных в URI (например, URI данных ), вы можете упаковать больше, если прописные и строчные буквы различны.

Уильям Хэй
источник
1
Я почти уверен, что URL-адреса исторически были ограничены ASCII. Так что интернационализация вряд ли будет оригинальной причиной. История Unix, учитывающая регистр символов, OTOH, вероятно, сыграла огромную роль.
Дероберт
В то время как только подмножество ASCII может использоваться без кодирования в URL, RFC1738 определенно заявляет, что символы вне диапазона ASCII могут использоваться закодировано. Без указания набора символов невозможно узнать, какие октеты представляют один и тот же символ, за исключением случая. Обновлено.
Уильям Хей
1
Re # 4: Это на самом деле хуже, чем это. Пунктирная и точечная. Я являюсь демонстрацией более общего принципа, согласно которому, даже если все UTF-8 (или какой-либо другой UTF), вы не можете правильно использовать заглавные или строчные буквы, не зная локали, к которой относится текст. В локали по умолчанию заглавная латинская буква I в нижнем регистре соответствует строчной латинской букве i, что по-турецки неверно, так как добавляет точку (отсутствует кодовая точка «Турецкая заглавная точка без I»; вы должны использовать код ASCII). точка). Добавьте различия в кодировке, и от «действительно сложного» до «совершенно неразрешимого».
Кевин
5

Я украл из блога «Старое новое» привычку подходить к вопросам вида «почему это так?» со встречным вопросом "на что был бы похож мир, если бы это было не так?"

Скажем, я настроил веб-сервер для обслуживания своих файлов документов из папки, чтобы я мог читать их по телефону, когда меня не было в офисе. Теперь в моей папке документов, у меня есть три файла, 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 по умолчанию на веб-сервере, чтобы сделать это ... но, возможно, они должны?

Деви Морган
источник
1
Некоторые сайты используют какой-то механизм для преобразования любого запроса во все строчные буквы или что-то непротиворечивое. В некотором смысле, это умно.
closetnoc
Нет, они не должны. Эта функциональность может быть и часто добавляется, когда это желательно (например, с помощью модулей в Apache.) Чтобы навязать такое изменение как поведение по умолчанию - или, что еще хуже, неизменное поведение - было бы более разрушительным, чем относительно редко случай, когда кто-то должен вручную ввести URL-адрес помимо имени хоста. Для хорошего примера, почему бы не сделать это, вспомните фиаско, когда Network Solutions «исправила» несуществующие доменные ошибки из публичных DNS-запросов.
SirNickity
@SirNickity Никто не предлагал неизменность на любом уровне, и страницы ошибок веб-сервера настраиваются на каждом веб-сервере, который я когда-либо использовал; никто не предлагал заменить 404 кодами на 30 *, а добавлял список ссылок, предлагаемых человеком, на которые можно кликнуть, на страницу ошибки; доменные имена - это совсем другая тема, и проблема не зависит от регистра и в другом контексте безопасности; и IIS уже автоматически «исправляет» (игнорируя) регистр различий в частях пути или имени файла URI.
Деви Морган
С 1996 года Apache позволяет вам делать это с помощью mod_speling . Кажется, это не очень популярно. Unix / Linux люди видят нечувствительность к регистру как правило, нечувствительность к регистру как исключение.
reinierpost
4

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

Чтобы лучше понять, нужно понимать принципиальную разницу между Unix (Linux) и Windows сервером. Unix чувствителен к регистру, а Windows не чувствительна к регистру ОС.

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

Большинство ученых были знакомы с Unix, поэтому на них могла повлиять файловая система в стиле Unix.

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

Это может быть причиной.

Mani
источник
2
«Сервер Windows был выпущен после 2000 года». Команда Windows NT 3.1 была бы не согласна с вами в 1993 году. NT 3.51 в 1995 году, вероятно, была тогда, когда NT начала становиться достаточно зрелой и хорошо зарекомендовавшей себя для поддержки критически важных для бизнеса серверных приложений.
CVn
NT 3.51 имеет интерфейс Win 3.1. Windows не взлетела на самом деле до Windows 95, и NT 4.0 потребовалось, чтобы получить тот же интерфейс.
Торбьерн Равн Андерсен
Майкл Кьёрлинг согласился. Позвольте мне изменить это.
Мани
1
@ ThorbjørnRavnAndersen На рынке серверов NT 3.51 была достаточно успешной. На рынке потребителей / потребителей потребовалось до Windows 2000 (NT 5.0), прежде чем линейка NT начала набирать обороты.
CVn
Действительно, WorldWideWeb изначально разрабатывался на Unix-системах, которые имеют чувствительные к регистру файловые системы, и большинство URL-адресов отображаются непосредственно на файлы в файловой системе.
reinierpost
4

Как следует читать «почему он был разработан таким образом?» вопрос? Вы спрашиваете о исторически точном отчете о процессе принятия решений, или вы спрашиваете «почему кто-то разработал бы его таким образом?»?

Очень редко можно получить исторически точный отчет. Иногда, когда решения принимаются в комитетах по стандартизации, есть документальный след о том, как проходили дебаты, но в первые дни веб-решений решения принимались поспешно несколькими людьми - в этом случае, вероятно, самим 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.

Майкл Кей
источник
Конечные пользователи также были пользователями Unix (не обязательно программистами, но физиками высоких энергий и т. П.), Поэтому они также привыкли к нечувствительности к регистру.
reinierpost
3

Это не имеет никакого отношения к тому, где вы купили свой домен, DNS не учитывает регистр. Но файловая система на сервере, который вы используете для хостинга, есть.

Это на самом деле не проблема, и она довольно распространена на хостах * nix. Просто убедитесь, что все ссылки, которые вы пишете на своих страницах, верны, и у вас не возникнет проблем. Чтобы сделать это проще, я рекомендую всегда называть свои страницы строчными буквами, тогда вам никогда не нужно дважды проверять имя при написании ссылки.

adnan3344
источник
2

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-адрес.

Майк
источник
«Да, чтобы избежать проблем с дублированием контента». - Но, похоже, все наоборот? Тот факт, что URL-адреса могут быть чувствительны к регистру (и именно так их обрабатывают поисковые системы), вызывает проблемы с дублированным содержимым, о которых вы упоминаете. Если бы URL были универсально нечувствительны к регистру, то не было бы повторяющихся проблем с контентом с другим регистром. page-1будет так же, как PAGE-1.
MrWhite
Я думаю, что плохая конфигурация сервера - это то, что может привести к дублированию контента, когда речь идет о корпусе. Например, оператор, RewriteRule ^request-uri$ /targetscript.php [NC]сохраненный в .htaccess, будет совпадать, http://example.com/request-uriи http://example.com/ReQuEsT-Uriпотому что [NC]указывает, что регистр не имеет значения при оценке этого одного регулярного выражения.
Майк
1

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

Если есть 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

Майкл д
источник