Кратко

  • RFC 2774 превращал GET в M-GET, а PUT в M-PUT, если запрос содержал обязательное расширение. Незнакомый с механизмом сервер должен был отвергнуть неизвестный метод, а не выполнить базовую операцию без важного условия.
  • Совместимый получатель отвечал 510, когда политика расширения не выполнялась, и присылал Ext или C-Ext после понимания и исполнения всех требований. Позднее эксперимент получил статус Historic, а его код и поля были объявлены устаревшими.

Успех, за которым скрывается другая операция

Пусть клиент отправляет ресурс методом PUT, но требует применить дополнительное правило. Новый сервер читает объявление расширения, соблюдает правило и сохраняет ресурс. Старый узнаёт только PUT, игнорирует неизвестные поля, сохраняет те же байты и возвращает 200 OK.

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

Экспериментальный RFC 2774, опубликованный в феврале 2000 года, сделал несовместимость намеренной. При обязательном расширении имя метода получало префикс M-. Сервер, не знающий рамочной модели, встречал M-PUT, а не обычный PUT, и должен был отказать до выполнения урезанной версии запроса.

Ошибка до побочного эффекта

Знающий механизм получатель не мог просто удалить префикс. Сначала он находил все обязательные объявления, определял поддержку каждого расширения для данного сообщения и возвращал 510 Not Extended, если хотя бы одно условие было невыполнимо. Лишь затем разрешалось применить расширения и семантику базового метода.

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

Четыре канала для требований

Расширения делились по двум признакам. Они могли быть обязательными или необязательными, сквозными или предназначенными для одного соединения. Получились поля Man, Opt, C-Man и C-Opt.

Матрица распределяла полномочия. Прокси не становился адресатом сквозного объявления лишь потому, что видел его. Условие на один переход предназначалось следующему участнику соединения и в HTTP/1.1 должно было быть защищено полем Connection вместе со связанными данными.

Расширение имело глобально уникальный URI; при более узком правиле идентификатором могло служить стандартизованное имя поля. Объявление резервировало цифровой префикс, например 16, после чего поля 16-... относились к этой конкретной инстанции. Так предотвращались конфликты имён без захвата всего пространства полей.

Узкое назначение 510

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

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

Код отделял доступность ресурса от смысловой состоятельности действия. Сервер мог работать, базовый метод мог быть известен, но контракт данной операции всё равно оставался невыполненным.

Для успеха требовалось отдельное подтверждение

Обычного успешного статуса было недостаточно. Ext подтверждал выполнение всех обязательных сквозных объявлений, а C-Ext — требований текущего перехода. Поля не несли прикладных данных; они свидетельствовали о понимании и соблюдении заявленной семантики.

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

Прокси и кэши умножали точки потери

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

Поэтому RFC 2774 использовал Cache-Control: no-cache="Ext" для ответа на выполненный обязательный сквозной запрос. Для прокси HTTP/1.0 добавлялся уже истёкший Expires. Если ответ зависел от поля с цифровым префиксом, Vary должен был назвать и это поле, и объявление, придающее ему смысл.

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

Официальное завершение эксперимента

Примечание IESG с самого начала было осторожным. Документ претендовал на Proposed Standard, но смешанные отзывы и отсутствие ясного согласия о развитии HTTP привели к статусу Experimental. Примечание не объявляло это доказательством технических дефектов и предостерегало от использования механизма как универсального шаблона.

В 2021 году IETF перевёл RFC 2774 и ряд других экспериментов HTTP в Historic. В официальной записи сказано, что эксперименты завершились и свидетельств широкого применения нет. IANA теперь обозначает 510 как Not Extended (OBSOLETED), а Man, Opt, C-Man, C-Opt, Ext и C-Ext — как obsoleted.

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

Расширения остались, матрица исчезла

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

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

HTTP 510 ушёл в историю, но названная им проблема никуда не делась. Доставка байтов не доказывает общего понимания. Самое опасное протокольное недоразумение — то, которое отвечает успехом.

Источники