Что такое HTTP-заголовок "Upgrade-Insecure-Requests"?

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

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 и теперь официально признаны.

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

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

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

2 ответов


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

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

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

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

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

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

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

...

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

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


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

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

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

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

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