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

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

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

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

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

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

Ответ 1

Цитата одного из моих предыдущих ответов:

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).

Остальные два предназначены для:

Обновление до TLS в HTTP/1.1 (почти никогда не используется, а не путайте с HTTP over TLS, который определяет HTTPS как широко используемый). Это обновление позволяет для аналогичного механизма для STARTTLS в другие протоколы (например, LDAP, SMTP,...), чтобы иметь возможность переключаться к TLS на том же порту, что и обычное соединение, после обмена некоторыми сообщений протокола приложения, в отличие от всего Обмен HTTP поверх SSL/TLS без необходимости знать его сверху TLS (способ HTTPS работает).

Обновление до WebSockets (все еще черновик).

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

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

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

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

Ответ 2

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

10.4.4 403 Запрещено

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

Есть прецедент для этого в Twitter API.

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