web-dev-qa-db-ja.com

HTTPステータスコード426 Upgrade Requiredは、安全なチャネルへのアップグレードが必要であることを示すだけですか？

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

その同期操作が既存のクライアントで静かに失敗する可能性があるEdgeのケースに遭遇しました。条件を適切に処理するために、クライアントの「同期プロトコル」をアップグレードしました。理想的には、古いクライアントすべてが同期を試みたときに、アップグレードするように指示するメッセージを受け取るようにしたいと考えています。

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

これを示すために使用するHTTP 426 Upgrade Required戻りコードの意図の粗雑化と見なされますか？すべてのリファレンス（ IETF RFC 2817 、 Wikipedia ）私は、クライアントにTLSにアップグレードするように通知するためにそれを使用することについて話します。これは、SSLやTLSのような明確に定義された/セキュリティプロトコルに限定されることを意図しているのですか、それとも、従来SSLおよびTLSにの​​み使用されてきたHTTPレイヤーの汎用アップグレードフラグですか？

このユースケースを対象としていない場合、HTTP 303 See Otherがより適切であると考えられますか、それとも他のコードがないのですか？

httprestssl
22
cclark

私の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仕様自体に含まれているものを含む）。

他の2つは、

（IANAレジスターはそれ以降変更されていません。）

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

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

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

12
Bruno

私は426が最良の選択ではないというブルーノに同意します。 400の方が優れていますが、 4 の方が優れています。

10.4.4 403 Forbidden

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEADでなく、サーバーがリクエストが満たされていない理由を公開したい場合は、エンティティに拒否の理由を記述してください。サーバーがこの情報をクライアントが利用できるようにするには、代わりにステータスコード404（見つかりません）を使用できます。

Twitter API にはこれに関する先例があります。

2014年2月26日以降、api.Twitter.comはすべての非SSL着信トラフィックに対して403ステータスコードを返します。クライアントコードはこのエラーを処理できる必要があります。

8
Chris H.