質問

HTTP（非HTTPS）サイトにPOSTリクエストを行い、Chromeのデベロッパーツールでリクエストを検査したところ、サーバーに送信する前に独自のヘッダーを追加していることがわかりました。

Upgrade-Insecure-Requests: 1

で検索した結果 Upgrade-Insecure-Requests のみ見つけることができます。 情報 を送信するサーバーについて これ ヘッダを表示します。

Content-Security-Policy: upgrade-insecure-requests

これは関連性があるように見えますが、私の場合、CLIENT がヘッダを リクエスト 一方、私が見つけたすべての情報は、サーバーが関連するヘッダを レスポンス .

では、なぜ Chrome (44.0.2403.130 m) は、次のようなものを追加しているのでしょうか。 Upgrade-Insecure-Requests をリクエストに追加して、何をするのですか？

2016-08-24に更新しました。

このヘッダーは、その後 W3C 勧告候補 であり、現在では公式に認められています。

この質問に出会ったばかりで、戸惑っている人のために エクセレントアンサー Simon East氏がうまく説明してくれています。

は、以下の通りです。 Upgrade-Insecure-Requests: 1 ヘッダーは、以前は HTTPS: 1 以前のW3C Working Draftでは という名前に変更され 静かに は、この変更が公式に受け入れられる前に、Chromeによって変更されました。

(この質問は、このヘッダーに関する公式文書がなく、Chrome がこのヘッダーを送信する唯一のブラウザであったこの移行期に行われました)。

解決方法は？

短い答え： それは Content-Security-Policy: upgrade-insecure-requests レスポンスヘッダをサポートすることを示すもので、ブラウザがこれを好むことを示します。

30分ほどググって、ようやくW3仕様の中に埋もれているのを発見しました。

混乱したのは、仕様書のヘッダーが HTTPS: 1 で、Chromiumはこのように実装しているのですが、この後 は、不適切にコーディングされた多くのウェブサイトを破壊しました。 (特にWordPressとWooCommerce）Chromiumチームは謝罪した。

開発中およびベータ版でのフィードバックに基づき、影響を過小評価していたようです。

- マイク・ウェスト、で Chrome 問題 501842

その修正方法は、名前を Upgrade-Insecure-Requests: 1 その後、仕様が更新され、一致するようになりました。

ともかく、以下はその説明です。 W3仕様 (当時は) ...

は HTTPS HTTPリクエストヘッダーフィールドは、サーバーにシグナルを送信します。 クライアントの好みを表現する 暗号化され認証された応答のため、そして upgrade-insecure-requests ディレクティブを正常に処理することができます。 を、できるだけシームレスに提供できるようにすることです。

...

サーバーは HTTP リクエストのヘッダーでこの設定に遭遇した場合、リクエストされたリソースの安全性の高い表現にユーザーをリダイレクトすべきです (SHOULD)。

サーバーが HTTPS リクエストのヘッダーでこのプリファレンスを見つけた場合、そのサーバーは Strict-Transport-Security ヘッダは、リクエストのホストがHSTS-safeまたは条件付きでHSTS-safe [RFC6797]の場合、レスポンスに含まれます。