Кратко

  • RFC 3205 рассматривал повторное использование HTTP как архитектурный выбор с унаследованным поведением, а не как автоматическую гарантию совместимости или безопасности.
  • Практическую обязанность он возлагал на разработчиков: определить идентичность службы, взаимодействие с прокси, кэширование и границу между ошибками HTTP и результатами приложения.

В этой сделке была ещё одна сторона

В начале 2002 года HTTP предлагал заманчивый набор средств для новых прикладных протоколов. Разработчики уже знали его, браузеры могли им пользоваться, клиентские и серверные библиотеки были доступны. Иногда можно было задействовать TLS и знакомые механизмы аутентификации. Если организация и так поддерживала веб-службу, использование той же инфраструктуры казалось способом удешевить прототип. В числе преимуществ называли и прохождение через межсетевые экраны.

BCP 56, подготовленный Keith Moore, включил в проектирование менее заметного участника: всю HTTP-среду между двумя конечными точками приложения. Запрос мог пройти через клиентскую библиотеку, прокси, кэш, межсетевой экран, транслятор адресов, веб-сервер и лишь затем попасть в код приложения. Каждый компонент применял к знакомым полям их общее значение. Сэкономив усилия на одном компоненте, нельзя заставить остальные понять специфический смысл приложения.

Документ прямо позиционировался как рекомендация, а не спецификация соответствия; поэтому он намеренно не использовал нормативные слова, набранные прописными буквами по правилам RFC 2119. Это не призыв всем отказаться от HTTP. Это требование оценивать последствия целиком. HTTP уже накопил постоянные соединения, диапазоны байтов, согласование содержимого и кэширование. Протокол поверх HTTP мог унаследовать ненужные функции, а затем тратить ресурсы на их ограничение.

Для небольших и частых транзакций накладные расходы TCP и HTTP могли быть существенными; постоянные соединения, напротив, позволяли распределить стоимость установления связи на несколько обменов.

Знакомый код состояния мог сообщить не то

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

RFC 3205 отделял ошибки в строке запроса и заголовках HTTP от результатов, передаваемых в теле приложения. Если прикладной протокол использовал общие ответы 200 или 500 для результатов обработки тела, в спецификации следовало описать защиту от вредного кэширования и поведение при изменении тела ошибки. Если протокол не выдерживал кэширования или модификации таких ответов прокси, документ советовал не использовать HTTP как основу. Речь не о том, что «коды HTTP плохи», а о том, что два уровня могут по-разному определять успех и отказ.

Та же граница проходит между методами и типами содержимого. Тип описывает, что за объект передаётся, но сам по себе не предписывает получателю выполнить над ним операцию. Действие нужно выразить отдельно. И новый метод HTTP ещё не отвечает на вопрос, нужен ли отдельной службе собственный порт или URI-схема.

Повторное использование — это ещё и выбор идентичности службы

Порт 80 и схема http: уже имели устоявшееся значение для операторов, программ и пользователей. RFC 3205 предлагал выяснить, использует ли новая служба отдельные данные, код, процесс или особые средства контроля трафика: такие различия могли оправдать выделенный порт. Широко используемой службе с иными настройками, учётными данными или порядком подготовки ресурсов могла понадобиться собственная URI-схема. Это вопрос эксплуатационной идентификации, а не красоты именования.

Библиотеки также приносили свои предположения. Клиент мог преобразовать адрес службы в HTTP-подобный URL, чтобы вызвать HTTP-библиотеку; затем прокси видел полный URL и мог трактовать его как обычный веб-запрос. Библиотека могла отправлять HTTP/1.1, хотя приложению ещё требовалось определить, что эта метка версии означает для его обмена. Описать отношения клиента, сервера и прокси должна была спецификация, а не надежда на повторно используемый код.

Следовательно, повторное использование переносило работу, а не отменяло её. Готовый код ускорял первую реализацию, но его общее поведение становилось частью системной границы. Чем больше появлялось независимых реализаций, тем вероятнее становилось столкновение клиентского упрощения с правилом кэширования или ожиданием сервера. Это вывод из анализа RFC 3205, а не измерение трудозатрат и не доказательство сбоя конкретного протокола.

Преемник показывает, что проблема сохранилась

В 2022 году RFC 9205 заменила RFC 3205 в роли BCP 56. После двух десятилетий развития HTTP новый документ рассматривает HTTP API, которые реализуют разные команды, несовпадающие циклы обновления клиентов и серверов, расширяемость, кэширование, состояние, аутентификацию и совместимость с обычным просмотром веб-страниц. Пересмотр показывает, что теме требовалось обновлённое руководство. Он не доказывает всеобщего соблюдения рекомендаций и не означает, что текст 2002 года предсказал всю последующую практику API.

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

Архитектурные термины для промежуточных устройств приведены в RFC 3234. Контекст HTTP/1.1 того периода дан в RFC 2616, а правила нормативных ключевых слов, от которых RFC 3205 отказалась, — в RFC 2119. Официальные источники: RFC 3205, запись RFC Editor, запись IETF Datatracker, RFC 9205 и её запись RFC Editor.