27

HTTPS 経由でサーバー上の RESTful API と通信するモバイル デバイスがあります。操作の 1 つは、オフライン中に行われた変更をサーバーにプッシュし、サーバー上で並行して行われた更新をプルダウンするデータ同期です。

その同期操作が既存のクライアントでサイレントに失敗するエッジ ケースに遭遇しました。この状態を適切に処理するために、クライアントの「同期プロトコル」をアップグレードしました。理想的には、すべての古いクライアントが同期しようとしたときに、アップグレードするように伝えるメッセージを受信するようにしたいと考えています。

通信はサーバーとモバイル クライアントの間でのみ行われるため、任意の数の HTTP コードを返し、クライアントに信号を送信して、ユーザーにアップグレードして同期プロセスをすぐに停止するようにアドバイスするメッセージを表示することができます。

HTTP 426 Upgrade Required リターン コードを使用してこれを通知することは、意図の粗悪品と見なされますか。私が見つけることができるすべての参照 ( IETF RFC 2817ウィキペディア) は、それを使用してクライアントに TLS にアップグレードするように通知することについて語っています。SSL や TLS などの明確に定義された/セキュリティ プロトコルに限定することを意図したものですか、それとも従来 SSL と TLS にのみ使用されてきた HTTP レイヤーの一般的なアップグレード フラグですか?

このユースケースを意図していない場合、HTTP 303 See Other がより適切であると見なされますか、それとも欠落している別のコードがありますか?

4

2 に答える 2

15

私の以前の回答の1つを引用します:

HTTP アップグレードは、可能であれば、別のバージョンの 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 仕様自体の 1 つを含む)。

他の 2 つは次の目的で使用されます。

(それ以来、IANA レジスターは変更されていません。)

RFC 2817で定義されている 426 応答コードは、明らかに RFC 2816 で定義されている「HTTP アップグレード」の意味でのアップグレードに関係しています。これは、現在使用されているレイヤー (つまり、HTTP 自体) での現在のプロトコルの変更です。http://(からへのアップグレードについてもまったくありませんhttps://。)

HTTP 上で交換されるメッセージ (プロトコルの一部である場合) は、この一部ではありません。HTTP に関する限り、それらは単なるハイパーメディア エンティティです。

ハイパーメディアの意味を変えると、426 は適していないと思います。普通の 400 がおそらくより良い選択でしょう。エラー ステータス コード (4xx、5xx) を持つ応答は、応答でエンティティを関連付けるのを妨げないことに注意してください。これは、クライアントにプロトコルを (そのレベルで) アップグレードするように伝えるメッセージがあるべき場所です。

于 2013-07-26T10:49:22.747 に答える