Интернет | URL

Единый указатель ресурса (англ. Uniform Resource Locator, URL) — единообразный локатор (определитель местонахождения) ресурса.

Ранее назывался Universal Resource Locator — универсальный указатель ресурса. URL служит стандартизированным способом записи адреса ресурса в сети Интернет.

История URL'а: домен, протокол и порт

11 января 1982 года двадцать два специалиста по информатике встретились, чтобы обсудить «компьютерную почту» (ныне известную как "электронная почта"). Среди участников был будущий основатель Sun Microsystems, парень, который сделал Zork, чувак, создавший NTP, и еще один, который убедил правительство платить за Unix. Перед ними стояла задача решить проблему: в ARPANET было 455 хостов, и ситуация выходила из под контроля.


Проблема возникла из-за того, что ARPANET переходил с оригинального протокола NCP на протокол TCP/IP, на котором сейчас существует Интернет. После такого перехода быстро должно было появиться множество объединенных сетей (inter...net), которым требуется иерархическая система доменов, чтобы ARPANET мог резолвить свои домены, а другие сети — свои.

В то время были другие сети: “COMSAT”, “CHAOSNET”, “UCLNET” и “INTELPOSTNET”. Их обслуживали группы университетов и компаний в США, которые хотели обмениваться информацией и которые могли позволить себе арендовать 56 тысяч соединений у телефонной компании и купить PDP-11 для маршрутизации.

В изначальной архитектуре ARPANET главный Центр Сетевой Информации (Network Information Center, NIC) отвечал за специальный файл, в котором содержится список всех хостов сети. Он назывался HOSTS.TXT, аналогично файлу /etc/hosts в современных Linux или macOS. Любое изменение в сети требовало от NIC подключаться к каждому узлу сети по FTP (протокол, созданный в 1971 году), что сильно повышало нагрузку на инфраструктуру.

Хранение всех хостов Интернета в одном файле, конечно, не могло считаться масштабируемым методом. Но приоритетным вопросом была электронная почта. Она была главной задачей адресации. В итоге, они решили создать иерархическую систему, в которой можно было бы запросить у удаленной системы информацию о домене или наборе доменов. Другими словами: «Решение заключалось в том, чтобы расширить существующий почтовый идентификатор вида 'user@host' до 'user@host.domain', где 'domain' может быть иерархией доменов». Так родился домен.


Важно отметить, что такие архитектурные решения были приняты без каких-либо предположений о том, как домены будут использоваться в будущем. Они были обусловлены лишь простотой реализации: это требовало минимальных изменений в существующих системах. Одним из предложений было формировать почтовый адрес как .@. Если бы в почтовых именах тех дней уже не было бы точек, то сегодня вы, возможно, писали бы мне на zack.eager@io

UUCP и Bang Path

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

— Дэвид Д. Кларк, 1982

Еще одно отклоненное предложение заключалось в том, чтобы отделить домен восклицательным знаком. Например, для подключения к хосту ISIA в сети ARPANET нужно было бы написать !ARPA!ISIA. Можно было бы использовать шаблоны: !ARPA!* — все хосты сети ARPANET.

Такой метод адресации не то чтобы безумно отличался от стандарта, наоборот, это была попытка поддержки стандарта. Система разделения с помощью восклицательного знака использовалась в инструменте для передачи данных UUCP, созданном в 1976 году. Если вы читаете эту статью в macOS или Linux, то uucp скорее всего все еще установлен и доступен в терминале.

ARPANET появилась в 1969 году и быстро превратилась в мощный инструмент обмена информацией… среди нескольких университетов и правительственных организаций, которые имели к ней доступ. Интернет в знакомом нам виде стал доступен широкой публике в 1991 году, спустя двадцать один год. Но это не значит, что пользователи компьютеров не обменивались информацией.


В эпоху до интернета использовался способ прямого подключения одной машины к другой через телефонную сеть. Например, если вы хотели послать мне файл, то ваш модем позвонил бы моему модему, и файл был бы передан. Чтобы сделать из этого некое подобие сети, был придуман UUCP.

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

sw-hosts!digital-lobby!zack


Такой адрес использовался не только для передачи файлов или прямого подключения к компьютеру, но и как адрес электронной почты. В эпоху до почтовых серверов вам не удалось бы послать мне письмо, если мой компьютер был отключен.

В то время, как ARPANET был доступен только топовым университетам, UUCP позволил появиться «подпольному» интернету для простых людей. Он был основой и для Usenet и для системы BBS.

DNS Система DNS, которую мы до сих пор используем, была предложена в 1983 году. Если сделать DNS-запрос с помощью утилиты dig, например, то ответ будет примерно таким:

;; ANSWER SECTION:
google.com. 299 IN A 172.217.4.206

Это значит, что google.com доступен по адресу 172.217.4.206. Как вы наверняка знаете, A означает, что это запись адреса, которая связывает домен с IPv4-адресом. Число 299 — это время жизни (time to live, TTL), сколько еще секунд эта запись считается валидной пока не понадобится делать новый запрос. Но что такое IN?

IN это "Internet". Наряду с другими деталями, это поле пришло из прошлого, в котором было несколько конкурирующих сетей, и им нужно было общаться друг с другом. Другие потенциальные значения для этого поля это CH для CHAOSNET, HS для Hesiod (название сервиса системы Athena). CHAOSNET давно закрылся, но сильно модифицированная версия Athena все еще используется студентами MIT. Список всех классов DNS доступен на сайте IANA, но не удивительно, что обычно используется только один из потенциальных вариантов.

TLD

Вероятность того, что будут созданы какие-то другие TLD крайне низка.

— Джон Постел, 1994

Когда было решено, что доменные имена должны располагаться иерархически, осталось определить корень иерархии. Такой корень обозначается точкой .. Заканчивать все доменные имена точкой — семантически верно, и такие адреса будут работать в браузере: google.com.

Первым TLD был .arpa. Пользователи могли использовать свои старые имена хостов ARPANET в период перехода. Например, если моя машина была в прошлом зарегистрирована как hfnet, то мой новый адрес был бы hfnet.arpa. Это было временным решением для периода смены системы. Серверным администраторам нужно было принять важное решение: какой из пяти TLD им выбрать? “.com”, “.gov”, “.org”, “.edu” или “.mil”?

Когда говорят, что DNS обладает иерархией, имеют ввиду, что есть набор корневых DNS-серверов, которые отвечают, например, за преобразование .com в адреса DNS-серверов зоны .com, которые в свою очередь вернут ответ на вопрос «как добраться до google.com». Корневая зона DNS состоит из тринадцати кластеров DNS-серверов. Кластеров только 13, потому что больше не помещается в один пакет UDP. Исторически сложилось, что DNS работает через UDP, поэтому ответ на запрос не может быть длиннее 512 байт.

Корневые DNS-сервера находятся в сейфах, внутри закрытых клеток. На сейфе стоят часы, чтобы проверять, не взломали ли видеонаблюдение. Учитывая, как медленно работает реализация DNSSEC, взлом одного из этих серверов позволит взломщику перенаправить весь трафик части пользователей интернета. Это сценарий крутейшего фильма, который еще ни разу не сняли.

Не удивительно, что DNS-сервера топовых TLD очень редко меняются. 98% запросов в корневые DNS-сервера — это запросы по ошибке, обычно из-за того, что клиенты не кэшируют свои результаты как надо. Это стало такой проблемой, что несколько операторов корневых серверов добавили специальные серверы только для того, чтобы отвечать «уходи!» всем людям, которые делают обратные запросы DNS по своим локальным IP-адресам.

Сервера TLD администрируются разными компаниями и правительствами по всему миру (Verisign отвечает за .com). Когда вы покупаете домен в зоне .com, примерно 18 центов уходит в ICANN, и 7 долларов 85 центов уходят в Verisign.

Punycode

Редко бывает, что забавное название, которое разработчики придумали для своего проекта, становится окончательным, публичным именем продукта. Можно назвать базу данных компаний Delaware (потому что в этом штате зарегистрированы все компании), но можно не сомневаться: когда дело дойдет до продакшена, она будет называться CompanyMetadataDatastore. Но изредка, когда все звезды сходятся и начальник в отпуске, одно название пробирается сквозь щель.

Punycode — это система для кодировки юникода в имена доменов. Проблема, которую она решает, проста: как записать , когда все системы интернета построены вокруг алфавита ASCII, в котором самый экзотический символ — это тильда?

Нельзя просто переключить доменные имена на unicode. Исходные документы, которые отвечают за домены, обязывают кодировать их в ASCII. Каждое устройство в интернете за последние сорок лет, включая маршрутизаторы Cisco и Juniper, которые использовались для доставки этой страницы, работают с учетом этого условия.

Сам веб никогда не ограничивался ASCII. Изначально стандартом должен был ISO 8859-1, который включал в себя все символы из ASCII, плюс набор специальных символов вроде ¼ и буквы с диакритическими знаками вроде ä. Но этот стандарт включал только латинские символы.

Это ограничение HTML'а было окончательно исключено в 2007, и в том же году Юникод стал самым популярным стандартом кодирования символов в вебе. Но домены все еще работали через ASCII.


Как вы могли догадаться, Punycode не был первой попыткой решить эту проблему. Вы скорее всего слышали про UTF-8, популярный способ кодирования Юникода в байты (число 8 в названии "UTF-8" означает 8 бит в одном байте). В 2000 несколько членов Инженерного совета Интернета (Internet Engineering Task Force) придумали UTF-5. Идея заключалась в кодировании Юникода пятибитными наборами. Далее каждые пять бит связывались с разрешенным символом (A-V и 0-9) в доменных именах. Например, если бы у меня был сайт про изучение японского языка, то адрес превратился бы в загадочный M5E5M72COA9E.com.

У такого метода есть несколько недостатков. Во-первых, символы A-V и 0-9 используются в закодированном выводе. То есть, если нужно использовать один из этих символов в самом названии домена, то их пришлось бы кодировать как и другие символы. Получаются очень длинные имена, и это серьезная проблема: каждый сегмент домена ограничен 63 символами. Домен на Бирманском языке был бы ограничен 16 символами. Но у всей этой затеи есть интересные последствия, например, Юникод таким образом можно передавать через код Морзе или телеграммой.

Отдельным вопросом было то, как клиенты будут понимать, что домен был закодирован именно таким способом, и можно показывать пользователю реальное имя вместо M5E5M72COA9E.com в адресной строке. Было несколько предложений, например, задействовать неиспользованный бит в ответе DNS. Но это был «последний неиспользованный бит в заголовке», и люди, отвечающие за DNS «очень не хотели отдавать его».

Еще одна идея заключалась в том, чтобы добавлять ra-- в начало каждого доменного имени, которое использует этот способ кодирования. В то время (середина апреля 2000) не было ни одного домена, который начинался бы с ra--. Я знаю интернет, поэтому уверен: кто-то сразу купил домен с ra— всем назло сразу после публикации того предложения.

Окончательное решение было принято в 2003 — использовать формат Punycode. Он включал в себя дельта-кодирование, которое помогало значительно укоротить закодированные доменные имена. Дельта-кодирование — это особенно хорошая идея в случае с доменами, потому что скорее всего все символы доменного имени находятся примерно в одной области таблицы Юникода. Например, два символа из Фарси будут ближе друг к другу, чем символ из Фарси и символ из Хинди. Чтобы понять, как это работает, давайте взглянем на пример с такой бессмысленной фразой:

В незакодированном виде это три символа[1610, 1584, 1597] (на основе их положения в Юникоде). Чтобы закодировать их, давайте сначала отсортируем их (запомнив исходный порядок): [1584, 1597, 1610]. Теперь можно сохранить наименьшее значение (1584), и расстояние (дельту) до следующего символа (13), и до следующего (23), так что передавать и хранить нужно меньше информации.

Далее Punycode эффективно (очень эффективно!) кодирует эти целые числа в символы, разрешенные в доменных именах, и добавляет xn— в начало строки чтобы сообщить клиентам о кодировании имени. Можно заметить, что все символы Юникода собраны в конце домена. Они хранят не только значения символов, но и их положение в имени. Например, адрес превратится в xn--sales-r65lm0e.com. Когда вы вводите символы Юникода в адресную строку браузера, они всегда кодируются таким способом.

Эта трансформация могла бы быть прозрачной, но тогда может возникнуть серьезная проблема безопасности. Есть символы Юникода, которые выводятся на экран идентично существующим символам ASCII. Например, вы скорее всего не заметите разницу между кириллической буквой “а” и латинской “a”). Если я зарегистрирую кириллический аmazon.com (xn--mazon-3ve.com), то вы можете не понять, что находитесь на другом сайте. По этой причине сайт .ws, выглядит в вашем браузере скучно: xn--vi8hiv.ws.

Протокол

Первая часть URL — это протокол, по которому нужно производить соединение. Самый распространенный протокол это http. Это простой протокол для передачи документов, который Тим Бернерс-Ли разработал специально для веба. Это был не единственный вариант. Некоторые считали, что нужно использовать Gopher. Gopher был разработан специально для отправки структурированных данных, по аналогии со структурой файлового дерева.

Например, при запросе на /Cars можно получить такой ответ:


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


Первым популярным протоколом был FTP. Его создали в 1971 году для получения списков и скачивания файлов на удаленных машинах. Gopher был логическим продолжением этой идеи, так как он предлагал похожий листинг, но также включал механизмы получения мета-информации о записях. Это означает, что его можно было использовать и для других задач, вроде ленты новостей или простой базы данных. Однако, ему не хватало свободы и простоты, которые характеризуют HTTP и HTML.

HTTP — это очень простой протокол, особенно по сравнению с альтернативами вроде FTP или даже HTTP/2, популярность которого сегодня растет. Во-первых, HTTP полностью текстовый, в нем не используются магические бинарные элементы (которые могли бы значительно улучшить производительность). Тим Бернерс-Ли правильно решил, что текстовый формат позволит поколениям программистов легче разрабатывать и отлаживать приложения, использующие HTTP.

HTTP также не делает никаких допущений по поводу содержания. Несмотря на то, что он был разработан специально для передачи HTML, он позволяет указать тип содержания (с помощью MIME Content-Type, который был новым изобретением в свое время). Сам протокол довольно прост.

GET /index.html HTTP/1.1
Host: www.example.com

Возможный ответ:


Чтобы уловить контекст, вспомните, что в основе сети лежит IP, протокол интернета. IP отвечает за передачу маленького пакета данных (около 1500 байтов) от одного компьютера другому. Поверх этого — TCP, который отвечает за передачу более крупных блоков данных вроде целых документов или файлов. TCP осуществляет гарантированную доставку с помощью множества IP-пакетов. Поверх этого живет протокол вроде HTTP или FTP, который указывает, какой формат данных использовать для пересылки с помощью TCP (или UDP или другого протокола) чтобы передать осмысленные и понятные данные.

Другими словами, TCP/IP посылает кучу байтов другому компьютеру, а протокол уровня HTTP объясняет, чем являются эти байты и что они означают.

Можно сделать свой протокол, если захочется, собирая байты из сообщений TCP как угодно. Единственное требование заключается в том, чтобы получатель говорил на том же языке. Поэтому принято стандартизировать эти протоколы.

Конечно, существуют менее важные протоколы. Например, есть протокол цитаты дня Quote of The Day (порт 17), и случайного символа Random Characters (порт 19). Они могут показаться забавными сегодня, но они помогают понять важность универсального протокола для передачи документов, которым был HTTP.

Порт

Историю Gopher и HTTP можно проследить по их номерам портов. Gopher — это 70, HTTP 80. Порт для HTTP был установлен (скорее всего Джоном Постелом из IANA) по запросу Тима Бернерса-Ли между 1990 и 1992 годами.

Концепция регистрации «номеров портов» появилась еще до интернета. В оригинальном протоколе NCP, на котором работала сеть ARPANET, удаленные адреса были идентифицированы с помощью 40 битов. Первые 32 указывали на удаленный хост, это похоже на то, как IP работает сегодня. Последние 8 бит назывались также AEN (“Another Eight-bit Number” или «Еще одно восьмибитное число»), и использовались для схожих с портом целей: разделить сообщения, имеющие разные предназначения. Другими словами, адрес указывал на машину, куда нужно доставить сообщение, а AEN (или номер порта) указывал на приложение, которому нужно доставить сообщение.

Они быстро запросили, чтобы пользователи регистрировали эти «номера сокетов» для ограничения потенциальных коллизий. Когда номера портов расширили до 16 бит в TCP/IP, процесс регистрации продолжился.

Не смотря на то, что у протоколов есть порт по умолчанию, имеет смысл позволять вручную указывать порт для упрощения локальной разработки и для работы с несколькими сервисами на одной машине. Такая же логика лежала в основе добавления www. в адреса сайтов. В то время было сложно представить, чтобы кто-то получал доступ к корню своего домена чтобы всего лишь захостить «экспериментальный» веб-сайт. Но если давать пользователям имя хоста для конкретной машины (dx3.cern.ch), то начнутся проблемы когда появится необходимость заменить машину. Если использовать общий поддомен (www.cern.ch), то можно свободно менять место, куда указывает этот адрес.

То, что посередине

Вы, наверное, знаете, что в URL двойной слэш (//) стоит между протоколом и второй частью:

http://eager.io

Этот двойной слэш был унаследован от компьютерной системы Apollo, которая была одной из первых сетевых рабочих станций. У команды Apollo появилась такая же проблема, что у Тима Бернерса-Ли: им нужен был способ отделять путь от машины, в которой находится этот путь. Они решили придумать специальный формат для пути:

//computername/file/path/as/usual

И сэр Тим скопировал эту схему. На самом деле, теперь он жалеет об этом решении. Он хотел бы, чтобы домен (в нашем примере example.com) был бы первой частью пути:

http:com/example/foo/bar/baz

История URL: путь, фрагмент, запрос и авторизация

URL'ы не должны были стать тем, чем стали: мудрёным способом идентифицировать сайт в интернете для пользователя. К сожалению, мы не смогли стандартизировать URN, который мог бы стать более полезной системой наименования. Считать, что современная система URL достаточно хороша — это как боготворить командную строку DOS и говорить, что все люди просто должны научиться пользоваться командной строкой. Оконные интерфейсы были придуманы, чтобы пользоваться компьютерами стало проще, и чтобы сделать их популярнее. Такие же мысли должны привести нас к более хорошему методу определения сайтов в Вебе.

— Дейл Догэрти, 1996

Есть несколько вариантов определения слова "интернет". Один из них — это система компьютеров, соединенных через компьютерную сеть. Такая версия интернета появилась в 1969 году с созданием ARPANET. Почта, файлы и чат работали в этой сети еще до создания HTTP, HTML и веб-браузера.

В 1992 году Тим Бернерс-Ли создал три штуки, благодаря которым родилось то, что мы считаем интернетом: протокол HTTP, HTML и URL. Его целью было воплотить понятие гипертекста в реальности. Гипертекст, в двух словах — это возможность создавать документы, которые ссылаются друг на друга. В те годы идея гипертекста считалась панацеей из научной фантастики, заодно с гипермедиа, и любыми другими словами с приставкой «гипер».

Ключевым требованием гипертекста была возможность ссылаться из одного документа на другой. В то время для хранения документов использовалась куча форматов, а доступ осуществлялся по протоколу вроде Gopher или FTP. Тиму нужен был надежный способ ссылаться на файл, так, чтобы в ссылке был закодирован протокол, хост в интернете и местонахождение на этом хосте. Этим способом стал URL, впервые официально задокументированный в RFC в 1994 году.

В начальной презентации World-Wide Web в марте 1992 Тим Бернерс-Ли описал его как «универсальный идентификатор документов» (Universal Document Identifier или UDI). Множество других форматов также рассматривались в качестве такого идентификатора: protocol: aftp host: xxx.yyy.edu path: /pub/doc/README
PR=aftp; H=xx.yy.edu; PA=/pub/doc/README;
PR:aftp/xx.yy.edu/pub/doc/README
/aftp/xx.yy.edu/pub/doc/README)


Этот документ также объясняет, почему пробелы должны кодироваться в URL (%20):

В UDI избегают использование пробелов: пробелы — это запрещенные символы. Это сделано потому, что часто появляются лишние пробелы когда строки оборачиваются системами вроде mail, или из-за обычной необходимости выровнять ширину колонки, а так же из-за преобразования различных видов пробелов во время конвертации кодов символов и при передаче текста от приложения к приложению.

Важно понимать, что URL был просто сокращенным способом обратиться к комбинации схемы, домена, порта, учетных данных и пути, которые ранее нужно было определять из контекста для каждой из систем коммуникации.

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

Эта позволило обращаться к разным системам из гипертекста, но сегодня, возможно, такая форма уже избыточна, так как практически все передается через HTTP. В 1996 браузеры уже добавляли http:// и www. за пользователей автоматически (что делает рекламу с этими кусками URL по-настоящему бессмысленной).

Путь

Я не считаю, что вопрос «могут ли люди понять значение URL» имеет смысл. Я просто думаю, что морально неприемлемо заставлять бабушку или дедушку вникать в то, что в конечном итоге является нормами файловой системы UNIX.

— Исраэль дель Рио, 1996

Слэш, отделяющий путь в URL, знаком любому, кто использовал компьютер за последние пятьдесят лет. Сама иерархическая файловая система была представлена в системе MULTICS. Ее создатель в свою очередь ссылается на двухчасовую беседу с Альбертом Эйнштейном, которая состоялась в 1952 году.

В MULTICS использовался символ «больше» (>) для разделения компонентов файлового пути. Например:

>usr>bin>local>awk

Это совершенно логично, но, к сожалению, ребята из Unix решили использовать > для обозначения перенаправления, а для разделения пути взяли слэш (/).

Битые ссылки в решениях Верховного Суда

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

… Как человек, я хочу сохранить за собой право использовать разные критерии для разных целей. Я хочу иметь возможность давать имена самим работам, и конкретным переводам и конкретным версиям. Я хочу более богатого мира чем тот, что вы предлагаете. Я не хочу ограничивать себя вашей двухуровневой системой «документов» и «вариантов».

— Тим Бернерс-Ли, 1993

Половины URL-адресов, на которые ссылается Верховный Суд США, уже не существует. Если вы читаете академическую работу в 2011 году, и написана она была в 2001 году, то с большой вероятностью любой URL там будет нерабочим.

В 1993 году многие страстно верили, что URL отомрет, и на замену ему придет URN. Uniform Resource Name — это постоянная ссылка на любой фрагмент, который, в отличие от URL, никогда не изменится и не сломается. Тим Бернерс-Ли описал его как «срочную необходимость» еще в 1991.

Простейший способ создать URN — это использовать криптографический хэш содержания страницы, например:urn:791f0de3cfffc6ec7a0aacda2b147839. Однако, этот метод не удовлетворяет критериям веб-сообщества, так как невозможно выяснить, кто и как будет конвертировать этот хэш обратно в реальный контент. Такой способ также не учитывает изменений формата, которые часто происходят в файле (например, сжатие файла), которые не влияют на содержание.


В 1996 Киф Шэйфер и несколько других специалистов предложили решение проблемы поломанных URL.

Я смог найти эти страницы через Google, который по сути сделал заголовки страниц современным аналогом URN. Формат URN был окончательно оформлен в 1997 году, и практически не использовался с тех пор. У него интересная реализация. Каждый URN состоит из двух частей: authority, который может преобразовать определенный тип URN, и конкретный идентификатор документа в понятном для authority формате. Например, urn:isbn:0131103628 будет обозначать книгу, формируя постоянную ссылку, которая (надеюсь) будет конвертирована в набор URL'ов вашим локальным преобразователем isbn.

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


Параметры запроса

Формат application/x-www-form-urlencoded — это аномальный монстр во многих отношениях, результат многих лет случайностей реализаций и компромиссов, которые привели к необходимому для интероперабельности набору требований. Но это точно не образец хорошей архитектуры.

— WhatWG URL Spec

Если вы использовали веб какое-то время, то вам знакомы параметры запросов. Они находятся после пути и нужны для кодирования параметров вроде ?name=zack&state=mi. Может показаться странным, что запросы используют символ амперсанда (&), который в HTML используется для кодирования специальных символов. Если вы писали на HTML, то скорее всего столкнулись с необходимостью кодировать амперсанды в URL, превращая
http://host/?x=1&y=2 в http://host/?x=1&y=2 или http://host?x=1&y=2

(конкретно эта путаница существовала всегда).

Возможно, вы также замечали, что куки (cookies) используют похожий, но все же иной формат: x=1;y=2, и он никак не конфликтует с символами HTML. W3C не забыл про эту идею и рекомендовал всем поддерживать как ;, так и & в параметрах запросов еще в 1995 году.

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

Так или иначе, физикам нужен был способ кодирования и связывания информации, и способ поиска этой информации. Для этого Тим Бернерс-Ли создал тег ISINDEX. Если ISINDEX присутствовал на странице, то браузер знал, что по этой странице можно делать поиск. Браузер показывал поисковую строку и позволял пользователю делать запрос на сервер.

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

http://cernvm/FIND/?sgml+cms

Как это обычно случается в интернете, тег стали использовать для всего подряд, в том числе как поле ввода числа для вычисления квадратного корня. Вскоре предложили принять тот факт, что такое поле слишком специфично, и нужен тег общего характера INPUT.

В том предложении использовался символ плюса для отделения компонентов запроса, но в остальном все напоминает современный GET-запрос:

http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

Далеко не все одобрили это. Некоторые считали, что нужен способ указать поддержку поиска по ту сторону ссылки:

search

Тим Бернерс-Ли думал, что нужен способ определения строго типизированных запросов:

ISINDEX TYPE="iana:/www/classes/query/personalinfo"

Изучая прошлое, готов с определенной долей уверенности сказать: я рад, что победило более общее решение.

Работа над тегом INPUT началась в январе 1993 года, она основывалась на более старом типе SGML. Было решено (пожалуй, к сожалению), что тегу SELECT нужна своя, более широкая структура:


Если вам любопытно, то да, была идея повторно использовать элемент LI вместо создания нового OPTION. Однако, были и другие предложения. В одном из них происходила замена переменных, что напоминает современный Angular:


В этом примере проверяется тип input'ов на основе указания type, а значения VAR доступны на странице для замены строк в URL, примерно так:

http://eager.io/apps/$appId

Дополнительные предложения использовали @ вместо = для разделения компонентов запроса:

name@value+name@(value&value)

Марк Андриссен предложил метод, основанный на том, что он уже реализовал в Mosaic:

name=value&name=value&name=value

Всего два месяца спустя Mosaic добавил поддержку method=POST в формы, и так родились современные HTML-формы.

Конечно, компания Netscape Марка Андриссена создала еще и формат куки (с другим разделителем). Их предложение было болезненно недальновидным, оно привело к попытке создания заголовка Set-Cookie2, и создало фундаментальные структурные проблемы, с которыми нам все еще приходится иметь дело в продукте Eager.

Фрагменты

Часть URL после символа ‘#’ известна как «фрагмент» (fragment). Фрагменты были частью URL со времен первой спецификации, они использовались для создания ссылки на конкретное место на загруженной странице. Например, если у меня есть якорь на сайте:

A name="bio"

Я могу сделать на него ссылку:

http://zack.is/#bio

Эта концепция постепенно была расширена до всех элементов (а не только якорей), и перешла на атрибут id вместо name:

... id="bio">Bio ...

Тим Бернерс-Ли решил использовать этот символ, основываясь на связи с форматом почтовых адресов в США (не смотря на то, что сам Тим — британец). По его словам:

Как минимум в США в почтовых адресах часто используют знак номера для указания номера квартиры или комнаты в здании. 12 Acacia Av #12 означает «Здание 12 на Акация Авеню, и в этом здании квартира 12». Этот символ казался естественным для такой цели. Сегодня http://www.example.com/foo#bar означает «На ресурсе http://www.example.com/foo конкретный вид, известный как bar”.

Оказывается, первичная система гипертекста, созданная Дугласом Энгельбартом, также использовала "#" для таких целей. Это может быть совпадением или случайным «заимствованием идеи».

Фрагменты специально не включаются в HTTP-запросы, то есть они живут исключительно в браузере. Такая концепция оказалась ценной, когда пришло время реализовывать клиентскую навигацию (до изобретения pushState). Фрагменты также были очень полезными, когда пришло время задуматься о сохранении состояния в URL без отправки на сервер. Что это значит? Давайте разберемся:

Кротовые холмики и горы

Есть целый стандарт, такой же мерзкий как SGML, созданный для передачи электронных данных, другими словами — для форм и отправки форм. Единственное, что мне известно: он выглядит как фортран задом наперед без пробелов.

— Тим Бернерс-Ли, 1993

Есть ощущение, разделяемое многими, что организации, отвечающие за стандарты интернета ничего особо не делали с момента окончательного принятия HTTP 1.1. и HTML 4.01 в 2002 до тех пор, пока HTML 5 не стал по-настоящему популярным. Этот период также известен (только для меня) как Темный Век XHTML. В реальности люди, занимающиеся стандартами, были безумно заняты. Просто они занимались тем, что в итоге оказалось не слишком ценным.

Одним из направлений было создание Семантического Веба. Была мечта: создать Фреймворк Описания Ресурсов (Resource Description Framework). (прим. ред.: бегите от любой команды, которая хочет сделать фреймворк). Такой фреймворк позволял бы универсально описывать мета-информацию о содержании. Например, вместо того, чтобы делать красивую веб-страницу про мой Корвет Стингрэй, я бы сделал RDF-документ с описанием размеров, цвета и количества штрафов за превышение скорости, которые мне выписали за все время езды.

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

Но эта идея хотя бы родила условия для философских споров. Один из лучших подобных споров длился как минимум десять лет, он известен под искусным кодовым именем ‘httpRange-14’.

Целью httpRange-14 было ответить на фундаментальный вопрос «чем является URL?». Всегда ли URL ссылается на документ или он может ссылаться на все, что угодно? Может ли URL ссылаться на мою машину?

Они не пытались ответить на этот вопрос хоть сколько-нибудь удовлетворительно. Вместо этого они фокусировались на том, как и когда можно использовать редирект 303 чтобы сообщить пользователю, что по ссылке нет документа, и перенаправить его туда, где документ есть. И на том, когда можно использовать фрагменты (часть после ‘#’), чтобы направлять пользователей на связанные данные.

Прагматичному современному человеку эти вопросы могут показаться смешными. Многие из нас привыкли, что если URL получается использовать для чего-то, то значит его можно использовать для этого. И люди или будут использовать ваш продукт, или нет.

Но Семантический Веб заботился только о семантике.

Авторизация

Как вы знаете, в URL можно включить логин и пароль:

http://zack:shhhhhh@zack.is

Браузер кодирует эти данные в формат Base64 и посылает в виде заголовка:

Authentication: Basic emFjazpzaGhoaGho

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

Это было проблемой, особенно до распространения SSL. Любой человек, который следит за вашим соединением, мог с легкостью увидеть пароль. Предлагали много альтернатив, в том числе Kerberos, который был и остается популярным протоколом безопасности.

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

Веб-приложение

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

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

© Рахим Давлеткалиев @freetonik / Zack Bloom

Источники:

Habrahabr.Ru: История URL'а. Часть 1,
Habrahabr.Ru: История URL'а. Часть 2.

В начало

Интернет | URL

ВКонтакте

Facebook