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

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

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

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

https://en.wikipedia.org/wiki/StAck_Exchange является DOA.

52 голоса | спросил Kyle 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 03:50:42 +0300000000amTue, 23 Feb 2016 03:50:42 +030016 2016, 03:50:42

10 ответов


7

Почему URL-адрес не будет чувствителен к регистру?

Я понимаю, что это может выглядеть как провокационный (и «дьявольский адвокат») тип риторического вопроса, но я думаю, что это полезно рассмотреть. Дизайн HTTP заключается в том, что «клиент», который мы обычно называем «веб-браузером», запрашивает «веб-сервер» для данных.

Существует много разных веб-серверов, выпущенных. Microsoft выпустила IIS с операционными системами Windows Server (и другими, включая Windows XP Professional). Unix имеет тяжеловесов, таких как nginx и Apache, не говоря уже о небольших предложениях, таких как внутренний httpd, или thttpd OpenBSD, или 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 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 18:39:05 +0300000000pmTue, 23 Feb 2016 18:39:05 +030016 2016, 18:39:05
70

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

Что касается RFC 3986 - Единый идентификатор ресурса (URI): общий синтаксис

Во-первых, из Wikipedia URL-адрес выглядит следующим образом:

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

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

  

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

  

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

  

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

  

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

  

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

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

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

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

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

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

Полезно ли это?

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

ответил Kobi 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 18:18:24 +0300000000pmTue, 23 Feb 2016 18:18:24 +030016 2016, 18:18:24
59

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

ответил closetnoc 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 04:54:19 +0300000000amTue, 23 Feb 2016 04:54:19 +030016 2016, 04:54:19
21
  1. URL-адреса утверждают, что они являются UNIFORM Resource locator и могут указывать на ресурсы которые предшествуют сети. Некоторые из них чувствительны к регистру (например, многие ftp-серверы) и URL-адреса должны быть способны представлять эти ресурсы разумно интуитивно.

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

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

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

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

ответил William Hay 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 17:43:24 +0300000000pmTue, 23 Feb 2016 17:43:24 +030016 2016, 17:43:24
5

Я украл из блога Old New Thing привычку приближаться к вопросам формы «почему это так?» с встречным вопросом: «Каким был бы мир, если бы это было не так?»

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

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

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

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

ответил Dewi Morgan 24 FebruaryEurope/MoscowbWed, 24 Feb 2016 05:09:33 +0300000000amWed, 24 Feb 2016 05:09:33 +030016 2016, 05:09:33
4

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

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

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

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

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

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

ответил Mani 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 09:44:52 +0300000000amTue, 23 Feb 2016 09:44:52 +030016 2016, 09:44:52
4

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

Очень редко можно получить исторически точную учетную запись. Иногда, когда принимаются решения в комитетах по стандартам, существует документальный след о том, как проходили дебаты, но в первые дни веб-решения были сделаны спешно несколькими лицами - в этом случае, вероятно, самим TimBL - и обоснование маловероятно чтобы быть записаны. Но TimBL признал, что ошибался в разработке URL-адресов - см. http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web- адрес-mistake.html

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

ответил Michael Kay 24 FebruaryEurope/MoscowbWed, 24 Feb 2016 21:04:04 +0300000000pmWed, 24 Feb 2016 21:04:04 +030016 2016, 21:04:04
3

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

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

ответил adnan3344 24 FebruaryEurope/MoscowbWed, 24 Feb 2016 10:59:06 +0300000000amWed, 24 Feb 2016 10:59:06 +030016 2016, 10:59:06
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-адрес.

ответил Mike 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 10:04:39 +0300000000amTue, 23 Feb 2016 10:04:39 +030016 2016, 10:04:39
1

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

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

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

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

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

Вот почему вы видите youtube с помощью URL-адресов, таких как https://www.youtube.com/смотреть? v = XXXXXXXX

ответил Michael d 19 FebruaryEurope/MoscowbMon, 19 Feb 2018 03:52:02 +0300000000amMon, 19 Feb 2018 03:52:02 +030018 2018, 03:52:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132