Я зробив запит POST на сайт HTTP (не HTTPS), ознайомився з цим запитом у Інструментах для розробників Chrome і виявив, що він додав власний заголовок перед відправкою на сервер:

Upgrade-Insecure-Requests: 1

Після здійснення пошуку Upgrade-Insecure-Requestsя можу знайти лише інформацію про сервер, який надсилає цей заголовок:

Content-Security-Policy: upgrade-insecure-requests

Це здається пов'язаним, але все-таки дуже різним, оскільки в моєму випадку КЛІЄНТ надсилає заголовок у запиті , тоді як вся знайдена я інформація стосується СЕРВЕРУ, що надсилає відповідний заголовок у відповіді .

То чому Chrome (44.0.2403.130 м) додає 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 хвилин Googling, але я нарешті знайшов його закопаним у специфікації W3.

Плутанина виникає через те, що заголовок у специфікації був HTTPS: 1, і ось як Chromium реалізував це, але після цього було порушено безліч веб-сайтів, які були кодовані погано (зокрема WordPress та WooCommerce), команда Chromium вибачилася:

"Прошу вибачення за поломку; я, очевидно, недооцінив вплив на основі зворотного зв'язку під час розробки та бета-версії".
- Майк Вест, у Chrome Issue 501842

Їх виправлення полягало в тому, щоб перейменувати його Upgrade-Insecure-Requests: 1, і специфікація з тих пір оновлюється, щоб відповідати.

У будь-якому випадку, ось пояснення від специфікації W3 (як це з’явилося в той час) ...

Поле HTTPSзаголовка HTTP запиту надсилає сигнал на сервер, що виражає перевагу клієнта зашифрованою та автентифікованою відповіддю, і що він може успішно обробляти директиву щодо оновлення-незахищених запитів , щоб зробити цю перевагу максимально бездоганною.

...

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

Коли сервер стикається з цією перевагою у заголовках запиту HTTPS, ВІДПОВІДНО включити Strict-Transport-Securityзаголовок у відповідь, якщо хост запиту безпечний для HSTS або умовно HSTS [RFC6797].

Це пояснює все:

Директива HTTP щодо захисту вмісту (CSP) щодо оновлення-незахищених запитів доручає користувачам-агентам обробляти всі незахищені URL-адреси сайту (ті, що подаються через HTTP) так, ніби вони були замінені захищеними URL-адресами (тими, що подаються через HTTPS). Ця директива призначена для веб-сайтів з великою кількістю незахищених застарілих URL-адрес, які потрібно переписати.

Директива щодо оновлення-незахищених запитів оцінюється перед блоком-змішаним контентом, і якщо він встановлений, останній фактично не працює. Рекомендується встановлювати одну чи іншу директиву, але не обидві.

Директива щодо оновлення-небезпечні запити не гарантуватиме, що користувачі, які відвідують ваш сайт через посилання на сторонні сайти, будуть оновлені до HTTPS для навігації верхнього рівня і, таким чином, не замінять заголовка суворої транспортної безпеки (HSTS), який як і раніше слід встановити відповідний максимальний вік, щоб користувачі не зазнавали атак відчистки SSL.

Джерело: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests