Кратко

  • В 1997 году статус 305 Use Proxy предлагал повторить запрос через прокси, адрес которого находился в поле Location.
  • В 1999 году команду ограничили одним запросом и ответом исходного сервера; в 2014-м её признали устаревшей из-за опасений по поводу настройки прокси внутри HTTP-обмена.

Вы спрашиваете в магазине о книге. Магазин вместо ответа присылает адрес посредника и просит обратиться через него. Книга осталась там, где лежала; поменялся человек за стойкой, через которую проходит ваш вопрос. У HTTP был код для такой сцены — 305 Use Proxy. Ответ сервера называл прокси, через который клиенту следовало повторить просьбу.

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

305 стоял среди кодов перенаправления, но управлял другой вещью. 301 сообщает новый URI самого ресурса. 305 оставлял ресурс на месте и менял маршрут к нему. У клиента уже могли быть собственные настройки прокси и границы доверия к посредникам. Ответ с удалённого сервера пытался вмешаться в этот выбор. Требовалось определить, на какой срок действует указание и кто вправе его выдавать.

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

Сама идея выбора прокси внутри HTTP-разговора сохранилась до следующего пересмотра. RFC 7231, вышедший в 2014 году, пометил 305 как устаревший. В списке изменений названо основание: угрозы безопасности при настройке прокси изнутри протокольного обмена. Проблема заключалась в самом механизме: HTTP-ответ назначал прокси, который получит следующий запрос клиента.

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

Прокси встречает запрос раньше конечного сервера. Поэтому право поставить его на пути — существенное право над ходом обмена. 305 пытался передать его серверному ответу. В 1999 году предписание сузили, в 2014-м убрали из действующих рекомендаций. Маленький код заставил протокол вслух ответить на вопрос, кто выбирает середину дороги.