Кратко

  • RFC 2068, опубликованный в январе 1997 года, определил поле Link в HTTP-ответе для описания связи между ресурсами, обычно запрошенным и ещё одним. Ответ мог нести несколько значений; смысл поля сопоставлялся с элементом LINK в HTML.
  • RFC 5988, октябрь 2010 года, зафиксировал, что RFC 2616, июнь 1999 года, убрал поле из-за недостаточного опыта реализации. Его статус стал неясным, хотя позже некоторые пользовательские агенты применяли поле и появились новые задачи.
  • RFC 5988 определил Link заново как средство передачи типизированных связей независимо от формата страницы. RFC 8288, октябрь 2017 года, заменил этот документ и сохранил HTTP-поле как одну из форм записи отношений между ресурсами.

Ссылка едет вместе с ответом

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

Стандарт HTTP/1.1 RFC 2068, вышедший в январе 1997 года, предложил именно такое место. Раздел 19.6.2.4 описал Link как поле, задающее связь между двумя ресурсами, обычно запрошенным и другим. Одна сущность могла содержать несколько значений. Параметр rel задавал тип связи, title давал человекочитаемую подпись, anchor позволял указать иную исходную точку. Текст прямо сравнивал поле с HTML-элементом LINK. Дорожный указатель к соседнему ресурсу оказался на конверте ответа, а не в его письме.

Место имеет значение для читателя. HTML-разметку разбирает тот, кто понимает HTML. Поле HTTP сопровождает ответ и тогда, когда тело имеет другой медиатип. Клиент, знающий поле, может прочитать типизированную связь до разбора тела. Но само поле не загружает цель и не заставляет приложение на неё переходить. Дальнейшее действие зависит от программы и смысла отношения для неё.

RFC 2068 поместил Link среди дополнительных возможностей. Неподалёку были описаны методы запросов LINK и UNLINK, предназначенные для создания и удаления отношений. Метод запроса и поле ответа — разные механизмы. Позднейшее возвращение поля не означает возвращения тех методов. Историю нельзя строить на одном совпавшем слове.

Пустое место в издании 1999 года

RFC 2616, опубликованный в июне 1999 года, заменил RFC 2068 без определения поля Link. Причину прямо назвал последующий RFC 5988: реализационного опыта было недостаточно. Авторы новой базовой редакции HTTP/1.1 имели уже описанную функцию, но не имели достаточно практики, чтобы закрепить её в основном тексте.

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

У исключения была дополнительная цена. RFC 5988 отметил, что положение Link стало неопределённым. Некоторые разработчики подумывали о заголовках, специфичных для отдельных приложений, вместо повторного использования общего поля. Единый способ описания отношения рисковал раздробиться на несколько несовместимых имён. Между тем ресурсам по-прежнему требовалось объявлять связи, в том числе когда их тело перестало быть HTML.

Тот же документ 2010 года сообщает, что после исключения некоторые пользовательские агенты реализовали поле, например для таблиц стилей, а также возникли дополнительные применения. «Некоторые» здесь существенное слово: оно указывает на примеры, но не даёт доли рынка. Этого хватало, чтобы прежний вопрос вернулся к авторам спецификаций с новыми материалами.

Возвращение без прописки в HTML

RFC 5988, опубликованный в октябре 2010 года, снова определил Link, обновив синтаксис при сохранении совместимости с прежним. В центре оказался более общий объект: у типизированной ссылки есть контекст, вид отношения, цель и необязательные свойства цели. Та же связь может быть записана в HTML, Atom или HTTP-поле. Способ записи не исчерпывает смысл связи.

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

RFC 5988 расширил реестр типов отношений, выросший вокруг Atom, добавив связи, известные из HTML. Зарегистрированный тип объясняет, как связаны два ресурса. Он не гарантирует доступности цели и не обязывает каждый клиент действовать. Браузер может искать таблицу стилей, архив — лицензию или другую версию. Словарь общий, действия различаются.

В октябре 2017 года RFC 8288 заменил RFC 5988, сохранив контекст, тип отношения, цель и необязательные свойства. Link остался одной из форм передачи такой структуры через HTTP. Документ различает веб-навигацию, которая ищет stylesheet в HTML и при желании в HTTP-поле, и приложение Atom с другими отношениями. Тип отношения объясняет связь ресурсов. Медиатип описывает формат представления, полученного от цели. Эти вопросы не совпадают.

Поэтому 2010 год — не просто возвращение абзаца, исчезнувшего в 1999-м. Исходный вариант перенёс близкую к HTML ссылку в поле HTTP. Документы 2010 и 2017 годов дали связи модель, проходящую через разные форматы, и процедуру регистрации её типов. Вернулось имя с более ясной работой.

Стандарт дождался новых следов работы

Последовательность кажется капризом, если считать публикацию равной внедрению. В 1997 году предложение было достаточно конкретным для описания. В 1999-м практики не хватило для места в новой базовой редакции. К 2010 году появилось ограниченное применение и новые случаи использования; в 2017-м модель перешла в следующий RFC. Редактор менял статус поля на бумаге, а работающие программы давали этому изменению основания.

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

Для подробной картины внедрения нужны датированные версии клиентских и серверных программ либо сохранённые HTTP-ответы. Цепочка RFC уже устанавливает институциональную траекторию: поле было описано, убрано при нехватке опыта и вновь определено, когда задача связи ресурсов вне HTML получила более ясный контур.