Является ли код статуса HTTP 426 Обновление Требуется только означало, что требуется обновление до безопасного канала?

Question

У меня есть мобильное устройство, взаимодействующее через HTTPS с RESTful API на моих серверах. Одной из операций является синхронизация данных с целью изменения настроек, сделанных в автономном режиме на сервере, и вытаскивание обновлений, сделанных параллельно на сервере.

Я столкнулся с краевым корпусом, где эта операция синхронизации может терпеть неудачу в существующем клиенте. Я обновил «протокол синхронизации» на клиенте, чтобы правильно обработать это условие. В идеале я хотел бы, чтобы все более старые клиенты получали сообщение, когда они пытались синхронизировать их, чтобы обновить их.

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

Будет ли это рассматриваться как уловка намерения HTTP 426 Upgrade Обязательный код возврата, чтобы использовать его для оповещения об этом. Каждая ссылка (IETF RFC 2817, Wikipedia) Я могу найти, чтобы использовать ее, чтобы сигнализировать клиенту об обновлении до TLS. Должен ли он ограничиваться четко определенными/протоколами безопасности, такими как SSL и TLS, или это общий флаг обновления на уровне HTTP, который использовался только для SSL и TLS традиционно?

Если это не предназначено для этого случая использования, HTTP 303 See Other считается более подходящим или есть другой код, который мне не хватает?

Answer 1

Цитируя одного из моих previous answers:

HTTP Upgrade используется для указания предпочтения или требования к переключиться на другую версию HTTP или другой протокол, если возможно:

The Upgrade general-header allows the client to specify what 
additional communication protocols it supports and would like to use 
if the server finds it appropriate to switch protocols. The server 
MUST use the Upgrade header field within a 101 (Switching Protocols) 
response to indicate which protocol(s) are being switched. 

     Upgrade  = "Upgrade" ":" 1#product 

    For example, 

    Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 

The Upgrade header field is intended to provide a simple mechanism 
for transition from HTTP/1.1 to some other, incompatible protocol. 

Согласно IANA register, упоминаются только 3 зарегистрированных (в том числе один в самой спецификации HTTP).

Другие два предназначены для:

• Upgrading to TLS Within HTTP/1.1 (почти никогда не используется, не следует путать с HTTP over TLS, который определяет HTTPS, как широко используется). Это обновление позволяет for a similar mechanism to STARTTLS in other protocols (например, LDAP, SMTP, ...), чтобы иметь возможность переключать на TLS на том же порту, что и обычное соединение, после обмена сообщений протокола приложения, в отличие от всего HTTP-обмен поверх SSL/TLS без необходимости знать, что он находится на вершине TLS (как работает HTTPS).

• Upgrading to WebSockets (еще черновик).

(регистр IANA не изменился с тех пор.)

код 426 ответа, как это определено в RFC 2817 явно связано с обновлением в «HTTP Upgrade» в определенном смысле RFC 2816. Это изменение текущего протокола на используемом в данный момент (например, самом HTTP).(Это даже не обновление от http:// до.)

Сообщения, обмениваемые поверх HTTP (если часть протокола вообще не являются), не являются частью этого. Это всего лишь объекты гипермедиа в отношении HTTP.

Я не думаю, что 426 был бы подходящим, если вы измените значение своей гипермедиа. Простой 400, вероятно, был бы лучшим выбором. Обратите внимание, что ответы с кодами состояния ошибок (4xx, 5xx) не мешают вам связывать сущность в ответе: здесь должно быть сообщение, сообщающее клиенту обновить ваш протокол (на этом уровне).

Answer 2

Я согласен с Бруно, что 426 - не лучший выбор. 400 лучше, но я думаю, что 403 все равно.

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается выполнять его. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться. Если метод запроса не был HEAD, и сервер хочет сообщить, почему запрос не был выполнен, ему ДОЛЖЕН описать причину отказа в сущности. Если сервер не хочет предоставлять эту информацию клиенту, вместо этого может использоваться код состояния 404 (Not Found).

Существует прецедент для этого на Twitter API.

С 26 февраля 2014 года api.twitter.com возвращает 403 код статуса для всего входящего трафика без SSL. Ваш код клиента должен иметь возможность обрабатывать эту ошибку.