2016-05-21 5 views
1

について、ステータスラインはHTTP1.1 HTTP/2 HTTP 1.1のバージョンヘッダ及び他の

scheme/version code reason 
HTTP/1.1 200 OK 

た私が見私はバージョンや理由のために何も見ない?それはありませんか?方法となるほど:私が考える経路は、完全絶対パス(同じではないだけの相対パスであるHTTP 1.1の要求で

、要求ラインは、私が見る

method uri scheme/version 
POST http://myhost.com HTTP/1.1 

ましたchromeとfirefoxはhttp2のhttpsを利用しているので、これは意味をなさないかもしれません)。私はバージョンヘッダーが表示されませんか?

バージョンヘッダーはありますか?それが本当に必要でないようなプロトコルの決定の前にいつも知られているのが見えますか?

理由コードはどうですか?これらはかなり不変であると仮定されていますので、私はここで推測しています。

おかげで、HTTP/1で ディーン

+0

[HTTP/2 RFC](http://httpwg.org/specs/rfc7540.html#discover-http)によると:「http "URIを要求するクライアント__サポートなしに事前知識なし__次のホップでHTTP/2のためにHTTPアップグレードメカニズムを使用する "。クライアントが既にHTTP/2をサポートしていることをクライアントがすでに知っている場合、最初はバージョン 'HTTP/2.0'を使用することができます。このHTTP2の導入ガイドの[リスト9](http://www.javaworld.com/article/2916548/java-web-development/http-2-for-java-developers.html?page=2)にもバージョンは 'HTTP/2.0'に設定されています –

+0

HTTP/2はちょうど2、" 2.0 " –

答えて

2

は、バージョントークンは、それらが同じワイヤ表現を持っていたことから、HTTP/1.1からHTTP/1.0を区別するために必要でしたが、異なる機能をサポートして。

たとえば、HTTP/1.1を宣言するクライアントは、永続的な接続とコンテンツチャンクをサポートすることを暗黙的にサーバーに伝えます。

HTTP/2の場合、プロトコルバージョンはとなり、となります。

クリアテキストHTTP/2では、Upgradeヘッダーにはh2cという報告があります。2はプロトコルのバージョン2を意味します。 HTTP/3の場合、トークンはh3cに変更されると思います。 トークンh2がALPN経由でネゴシエートされている暗号化されたHTTP/2でも同様です。

理由コードは、ステータスコードがすべての必要な情報を既に伝えていたため(迷惑メールになる可能性はありません)、重複しているとして削除されました。

これらの理由から、HTTP/2には、バージョン疑似ヘッダーも理由もありません。