Что такое 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.