Summary

  • В описании HTTP, реализованного для Всемирной паутины в 1991 году, один запрос GET возвращал HTML-документ, а сервер обозначал его конец закрытием соединения.
  • В этом кратком обмене не было ни строки состояния, ни заголовков. Заметки о проекте указывают, что ошибка возвращалась как документ и отличалась от успеха только текстом.
  • Позднее HTTP добавил версию, заголовки и коды состояния, сохранив простую форму ради совместимости; это не показывает, насколько широко применялся HTTP/0.9.

Страница и была всем ответом

В описанной в 1991 году реализации World Wide Web клиент сначала устанавливал соединение с сервером; если в адресе не был указан порт, использовался порт 80. Затем клиент отправлял строку с GET и идентификатором документа. Сервер возвращал поток байтов HTML и закрывал соединение после передачи документа. Перед страницей не было отдельной строки состояния, а за ней не следовал блок заголовков: первые полученные байты уже относились к документу.

В архивном описании Tim Berners-Lee нет невидимой HTTP-оболочки вокруг каждой страницы. Ответ назван сообщением HTML, а закрытие соединения завершало передачу. Сервер мог вернуть и понятный человеку текст ошибки в формате HTML. Там же прямо названа цена такого устройства: отличить ошибочный ответ от успешного можно было только по самому тексту. Браузер мог показать полученное содержимое, но формат не давал машине кода для «не найдено», перенаправления или ошибки сервера.

В обзоре июня 1992 года компромисс описан ясно. Браузер отправлял только одну команду — GET — с идентификатором документа; к запросу именованного индекса можно было добавить ключевые слова. Сервер не хранил состояние, связанное с браузером. Ответ мог быть HTML или обычным текстом и содержать документ, меню либо список результатов. Простота была преимуществом: с сервера выходил только размеченный текст. Однако обзор отмечал отсутствие языковой границы между информацией HTTP, содержимым документа и его типом. Сообщение об ошибке оставалось документом, который читатель мог пропустить.

Эта неоднозначность была свойством формата сообщения. Она не доказывает, что ранние серверы часто отказывали или что люди не могли понять страницу с ошибкой. Человек прочитает текст, а программа не найдёт поля состояния. Кроме того, закрытие соединения отмечало как нормальный конец документа, так и прекращение прерванного обмена. Клиент видел, что поток остановился, но сам протокол не объяснял почему.

Ранний дизайн не ограничивался статическими страницами. Элемент ISINDEX мог подсказать браузеру сформировать запрос, добавив ключевые слова к идентификатору документа; сервер мог вернуть список результатов в HTML. В тексте о причинах создания нового протокола Berners-Lee также называет поиск по индексам, автоматическое согласование формата и направление клиента на другой сервер среди нужных возможностей информационного доступа. Это цели более широкого дизайна, а не доказательство, что однострочный простой обмен уже реализовывал каждую из них.

Добавить сведения, не забывая старую форму

Публичное письмо в списке www-talk за декабрь 1992 года показывает предложение по развитию протокола. Berners-Lee предлагал сохранить распознавание GET <url> новыми серверами, а клиентам разрешить добавлять к той же строке обозначение версии, а затем заголовки From, Accept и Accept-Encoding. В примере ответа присутствовали версия, поле результата, тип MIME и перечень разрешённых методов. Это обсуждавшееся предложение, а не окончательная запись реально развернутого формата. Но оно показывает, что ответу требовалось описывать себя, а не только передавать содержание.

RFC 1945, опубликованный в 1996 году как информационный документ, позднее описал обе формы. Простой запрос оставался GET с URI без заголовков; простой ответ содержал только тело и завершался закрытием соединения сервером. Полный ответ начинался со строки состояния и мог включать заголовки ответа и сущности. RFC отдельно предупреждал: в простом запросе сервер не может указать тип возвращаемых данных. Сохранение распознаваемости прежней формы позволяло более поздним HTTP-системам учитывать старых клиентов и серверы, не делая вид, что они обменивались одинаковыми сообщениями.

Важна и хронология. Ретроспективное определение в RFC помогает понять совместимость, но не доказывает, что отдельный стандарт HTTP/0.9 был утверждён в 1991 году. Позднее Berners-Lee вспоминал, что первый веб-сервер и клиентские программы, включая построчный браузер Nicola Pellow, летом 1991 года появились сначала у сообщества физики высоких энергий, затем у групп, занимавшихся гипертекстом и NeXT. По его словам, спецификации URI, HTML и HTTP разместили на первом сервере, чтобы стимулировать обсуждение и внедрение. Эти источники дают контекст эксперимента, но не подсчитывают установки с каждой формой сообщения.

Ответ, состоявший из документа, делал систему понятной: запросить ресурс и получить содержимое, которое можно показать. Ограничение проявилось, когда клиенту понадобилось обрабатывать ответ как событие протокола. Без строки состояния HTML-ошибка и обычная страница занимали одно место. Более полные сообщения HTTP разделили результат, метаданные и представление, а простая форма осталась распознаваемой ради совместимости.

Источники