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

Upgrade-Insecure-Requests: 1

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

Content-Security-Policy: upgrade-insecure-requests

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

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

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

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

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

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

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

Ответ 1

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

Мне понадобилось 30 минут Googling, но я, наконец, нашел его зарытым в спецификации W3.

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

"Я приношу извинения за поломку, я, по-видимому, недооценил влияние, основанное на обратной связи во время dev и beta".
- Майк Уэст, в Chrome Issue 501842

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

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

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

...

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

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