Я сделал запрос POST на сайт HTTP (не HTTPS), проверил запрос в Chrome Developer Tools и обнаружил, что он добавил свой собственный заголовок перед отправкой на сервер:

Upgrade-Insecure-Requests: 1

После выполнения поиска Upgrade-Insecure-Requestsя могу только найти информацию о сервере, отправляющем этот заголовок:

Content-Security-Policy: upgrade-insecure-requests

Это кажется связанным, но все же сильно отличающимся, поскольку в моем случае КЛИЕНТ отправляет заголовок в Запросе , тогда как вся информация, которую я нашел, касается СЕРВЕРА, отправляющего связанный заголовок в Ответе .

Так почему же Chrome (44.0.2403.130 m) добавляет Upgrade-Insecure-Requestsк моему запросу и что он делает?

Обновление 2016-08-24:

Этот заголовок с тех пор был добавлен как Рекомендация кандидата W3C и теперь официально признан.

Для тех, кто только что столкнулся с этим вопросом и смущен, превосходный ответ Саймона Востока это хорошо объясняет.

Upgrade-Insecure-Requests: 1Заголовок , используемый как HTTPS: 1 в предыдущей W3C Working Draft и был переименован спокойно на Chrome до изменения стало официально принято.

(Этот вопрос задавался во время этого перехода, когда не было официальной документации по этому заголовку, и Chrome был единственным браузером, который отправил этот заголовок.)

Краткий ответ: он тесно связан с Content-Security-Policy: upgrade-insecure-requestsзаголовком ответа, указывая на то, что браузер его поддерживает (и на самом деле предпочитает).

Это заняло у меня 30 минут поиска в Google, но я наконец нашел его в спецификации W3.

Путаница возникает из-за того, что заголовок в спецификации был HTTPS: 1, и именно так Chromium реализовал его, но после того, как это сломало множество плохо кодированных веб-сайтов (особенно WordPress и WooCommerce), команда Chromium извинилась:

«Я извиняюсь за поломку; я, очевидно, недооценил влияние, основанное на обратной связи во время разработки и бета-тестирования».
- Майк Уэст, в выпуске Chrome 501842

Их исправление состояло в том, чтобы переименовать его Upgrade-Insecure-Requests: 1, и спецификация с тех пор была обновлена, чтобы соответствовать.

Во всяком случае, вот объяснение из спецификации W3 (как оно появилось в то время) ...

Поле HTTPSзаголовка HTTP-запроса отправляет серверу сигнал, выражающий предпочтение клиента для зашифрованного и аутентифицированного ответа, и что он может успешно обработать директиву upgrade-insecure-запросы , чтобы сделать это предпочтение как можно более незаметным.

...

Когда сервер встречает это предпочтение в заголовках HTTP-запроса, он ДОЛЖЕН перенаправить пользователя на потенциально безопасное представление запрашиваемого ресурса.

Когда сервер встречает это предпочтение в заголовках HTTPS-запроса, он ДОЛЖЕН включать Strict-Transport-Securityзаголовок в ответ, если хост запроса является HSTS-безопасным или условно HSTS-безопасным [RFC6797].

Это объясняет все это:

Директива HTTP-Content-Security-Policy (CSP) upgrade-insecure-запросы предписывает агентам пользователя обрабатывать все небезопасные URL-адреса сайта (те, которые обслуживаются по HTTP), как если бы они были заменены на безопасные URL-адреса (те, которые обслуживаются по HTTPS). Эта директива предназначена для веб-сайтов с большим количеством небезопасных устаревших URL-адресов, которые необходимо переписать.

Директива upgrade-insecure-reports оценивается перед block-all-mixed-content, и если она установлена, последняя фактически не работает. Рекомендуется устанавливать одну или другую директиву, но не обе.

Директива upgrade-insecure-reports не гарантирует, что пользователи, посещающие ваш сайт по ссылкам на сторонних сайтах, будут обновлены до HTTPS для навигации верхнего уровня и, таким образом, не заменят заголовок Strict-Transport-Security (HSTS), который должен по-прежнему быть установлен с соответствующим максимальным возрастом, чтобы гарантировать, что пользователи не будут подвергаться атакам разборки SSL.

Источник: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests