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

Upgrade-Insecure-Requests: 1

で検索を行った後、このヘッダーを送信しているサーバーに関する情報Upgrade-Insecure-Requestsしか見つかりません。

Content-Security-Policy: upgrade-insecure-requests

これは関連しているようですが、私の場合、クライアントはリクエストでヘッダーを送信しているので非常に異なっていますが、私が見つけたすべての情報はサーバーがレスポンスで関連ヘッダーを送信することに関するものです。

では、なぜChrome（44.0.2403.130 m）がUpgrade-Insecure-Requestsリクエストに追加され、何をするのですか？

2016年8月24日更新：

このヘッダーは、W3C候補の推奨事項として追加されています現在公式に認められています。

この質問に遭遇したばかりで混乱している人にとって、Simon Eastの優れた答えはそれをよく説明しています。

Upgrade-Insecure-Requests: 1ヘッダがあることを使用HTTPS: 1 前のW3Cワーキングドラフトでと改称静かに変更が正式に受け入れなる前クロームで。

（この質問は、このヘッダーに関する公式のドキュメントがなく、Chromeがこのヘッダーを送信した唯一のブラウザーであったときに、この移行中に尋ねられました。）

短い答え：これはContent-Security-Policy: upgrade-insecure-requests応答ヘッダーと密接に関連しており、ブラウザーがそれをサポートしていることを示しています（実際にはそれを好みます）。

グーグルで30分かかりましたが、ようやくW3仕様に埋め込まれていることがわかりました。

混乱は、仕様のヘッダーがHTTPS: 1であり、これがChromiumによる実装であったために発生しますが、これが適切にコーディングされていない多くのWebサイト（特にWordPressとWooCommerce）を壊した後、Chromiumチームは謝罪しました。

「私はこの破損をお詫びします。開発とベータ中のフィードバックに基づいて、影響を過小評価していたようです。」
— Mike West、Chrome Issue 501842

彼らの修正はそれをに名前を変更することでしたUpgrade-Insecure-Requests: 1、そして仕様は一致するように更新されました。

とにかく、W3スペック（当時の姿）からの説明はこちら...

HTTPSHTTPリクエストヘッダフィールドは、サーバに信号を送り、クライアントの好み表現暗号化と認証された応答のために、それが正常にアップグレード-安全でない-リクエストディレクティブを処理することができます提供するために、可能な限りシームレスように、その優先順位を作るために。

...

サーバーは、HTTPリクエストのヘッダーでこの設定に遭遇すると、リクエストされているリソースの潜在的に安全な表現にユーザーをリダイレクトする必要があります（SHOULD）。

サーバーがHTTPSリクエストのヘッダーでこの設定を検出するとStrict-Transport-Security、リクエストのホストがHSTSセーフまたは条件付きHSTSセーフである場合、サーバーはレスポンスにヘッダーを含める必要があります[RFC6797]。

これは全体を説明しています：

HTTP Content-Security-Policy（CSP）のupgrade-insecure-requestsディレクティブは、サイトのすべての安全でないURL（HTTP経由で提供される）が安全なURL（HTTPS経由で提供される）に置き換えられたかのように扱うようにユーザーエージェントに指示します。このディレクティブは、書き換えが必要な安全でないレガシーURLが多数あるWebサイトを対象としています。

upgrade-insecure-requestsディレクティブは、block-all-mixed-contentの前に評価され、設定されている場合、後者は事実上何もしません。どちらか一方のディレクティブを設定することをお勧めしますが、両方は設定しないでください。

upgrade-insecure-requestsディレクティブは、サードパーティサイトのリンクを介してサイトにアクセスするユーザーがトップレベルのナビゲーション用にHTTPSにアップグレードされることを保証しないため、Strict-Transport-Security（HSTS）ヘッダーを置き換えません。ユーザーがSSLストリッピング攻撃を受けないようにするには、適切なmax-ageを設定する必要があります。

ソース：https : //developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests