HTTP/1.1 アップグレード ヘッダー

アップグレードヘッダーフィールドは、 HTTP/1.1で導入されたHTTP ヘッダー フィールドです。交換では、クライアントはクリアテキストリクエストを行うことから開始し、後で新しいHTTPプロトコル バージョンにアップグレードされるか、別のプロトコルに切り替えられます。接続のアップグレードはクライアントによって要求される必要があります。サーバーがアップグレードを強制する場合は、応答が送信されることがあります。その後、クライアントは接続を開いたまま、適切なアップグレード ヘッダーを含む新しいリクエストを送信できます。 426 Upgrade Required

1つの用途は、通常のHTTPポートでリクエストを開始し、トランスポート層セキュリティ（TLS）に切り替えることです。^[1]実際には、このような使用法はまれであり、暗号化されたHTTPを開始するにはHTTPSの方がはるかに一般的な方法です。

サーバーは426 ステータス コードを返します。障害がクライアント関連であったことをレガシー クライアントに警告します (400レベル コードはクライアント障害を示します)。

安全な接続を確立するこの方法は、次のような利点があります。

• サーバー側での面倒で問題のあるURL リダイレクトを必要としません。
• 保護されたウェブサイトの仮想ホスティングを有効にします（ただし、HTTPS ではServer Name Indication を使用してこれも可能です）。
• 特定のリソースにアクセスするための単一の方法を提供することで、ユーザーの混乱の可能性を軽減します。

暗号化された安全な手段と暗号化されていないクリアな手段の両方を介してサーバーから同じリソースが利用できる場合、中間者はサーバーとの暗号化された接続を維持しながら、クライアントとの暗号化されていない認証されていない接続を維持する可能性があります。

この方法の欠点は次のとおりです。

• クライアントはURIでセキュアなHTTPの要件を指定できません（ただし、クライアントはアップグレードネゴシエーションを通じてそれを要求できます）。
• HTTP はホップベースで定義されるため、プロキシ サーバーをバイパスするにはHTTP トンネリングが必要になる場合があります。

WebSocketもこのメカニズムを使用して、互換性のある方法で HTTP サーバーとの接続を設定します。^[2] WebSocket プロトコルは、アップグレードされた接続を確立するためのハンドシェイクUpgrade: WebSocketと、実際のデータ転送の 2 つの部分で構成されます。最初に、クライアントは、およびヘッダーを使用して WebSocket 接続を要求しConnection: Upgrade、いくつかのプロトコル固有のヘッダーを使用して、使用されているバージョンを確立し、ハンドシェイクを設定します。サーバーは、プロトコルをサポートしている場合、同じUpgrade: WebSocketおよびConnection: Upgradeヘッダーで応答し、ハンドシェイクを完了します。^[3] ハンドシェイクが正常に完了すると、データ転送が開始されます。

HTTP アップグレード メカニズムは、プレーン HTTP からHTTP/2を確立するために使用されます。 ^[4] クライアントは HTTP/1.1 接続を開始し、Upgrade: h2cヘッダーを送信します。サーバーが HTTP/2 をサポートしている場合は、HTTP 101 スイッチング プロトコルステータス コードで応答します。HTTP アップグレード メカニズムは、クリアテキスト HTTP2 (h2c) にのみ使用されます。HTTP2 over TLS (h2) の場合は、代わりにALPN TLS プロトコル拡張が使用されます。

• 機会主義的暗号化
• セキュアハイパーテキスト転送プロトコル

• IANAのハイパーテキスト転送プロトコル (HTTP) アップグレード トークン レジストリ