Tôi đã thực hiện một yêu cầu POST đến trang web HTTP (không phải HTTPS), đã kiểm tra yêu cầu trong Công cụ dành cho nhà phát triển của Chrome và thấy rằng nó đã thêm tiêu đề của riêng mình trước khi gửi nó đến máy chủ:

Upgrade-Insecure-Requests: 1

Sau khi thực hiện tìm kiếm trên Upgrade-Insecure-Requests, tôi chỉ có thể tìm thấy thông tin về máy chủ gửi tiêu đề này :

Content-Security-Policy: upgrade-insecure-requests

Điều này có vẻ liên quan, nhưng vẫn rất khác vì trong trường hợp của tôi, CLIENT đang gửi tiêu đề trong Yêu cầu , trong khi tất cả thông tin tôi tìm thấy đều liên quan đến SERVER gửi tiêu đề liên quan trong Phản hồi .

Vậy tại sao Chrome (44.0.2403.130 m) thêm Upgrade-Insecure-Requestsvào yêu cầu của tôi và nó làm gì?

Cập nhật 2016-08-24:

Tiêu đề này đã được thêm vào dưới dạng Khuyến nghị của Ứng viên W3C và hiện đã được chính thức công nhận.

Đối với những người vừa gặp câu hỏi này và bối rối, câu trả lời tuyệt vời của Simon East giải thích nó rất tốt.

Các Upgrade-Insecure-Requests: 1tiêu đề được sử dụng là HTTPS: 1 trong Dự thảo W3C Working trước và được đổi tên lặng lẽ bởi Chrome trước khi thay đổi trở thành chính thức chấp nhận.

(Câu hỏi này đã được hỏi trong quá trình chuyển đổi này khi không có tài liệu chính thức nào về tiêu đề này và Chrome là trình duyệt duy nhất đã gửi tiêu đề này.)

Câu trả lời ngắn: nó liên quan chặt chẽ đến Content-Security-Policy: upgrade-insecure-requeststiêu đề phản hồi, chỉ ra rằng trình duyệt hỗ trợ nó (và trên thực tế thích nó hơn).

Nó đã cho tôi 30 phút của Google, nhưng cuối cùng tôi đã tìm thấy nó bị chôn vùi trong thông số W3.

Sự nhầm lẫn xuất hiện bởi vì tiêu đề trong thông số kỹ thuật là HTTPS: 1và đây là cách Chromium triển khai nó, nhưng sau khi điều này phá vỡ rất nhiều trang web được mã hóa kém (đặc biệt là WordPress và WooC Commerce), nhóm Chromium đã xin lỗi:

"Tôi xin lỗi vì sự cố này; rõ ràng tôi đã đánh giá thấp tác động dựa trên phản hồi trong quá trình phát triển và beta."
- Mike West, trong số phát hành Chrome 501842

Cách khắc phục của họ là đổi tên thành Upgrade-Insecure-Requests: 1và thông số kỹ thuật đã được cập nhật để phù hợp.

Dù sao, đây là lời giải thích từ thông số W3 (như nó xuất hiện vào thời điểm đó) ...

Trường HTTPStiêu đề yêu cầu HTTP gửi tín hiệu đến máy chủ thể hiện ưu tiên của máy khách đối với phản hồi được mã hóa và xác thực và nó có thể xử lý thành công chỉ thị yêu cầu nâng cấp-không an toàn để cung cấp tùy chọn đó liền mạch nhất có thể.

...

Khi một máy chủ gặp tùy chọn này trong các tiêu đề của yêu cầu HTTP, nó NÊN chuyển hướng người dùng đến một đại diện có khả năng bảo mật của tài nguyên đang được yêu cầu.

Khi máy chủ gặp tùy chọn này trong các tiêu đề của yêu cầu HTTPS, nó NÊN bao gồm một Strict-Transport-Securitytiêu đề trong phản hồi nếu máy chủ của yêu cầu là HSTS an toàn hoặc có điều kiện HSTS an toàn [RFC6797].

Điều này giải thích toàn bộ:

Chỉ thị yêu cầu nâng cấp chính sách bảo mật nội dung (CSP) HTTP (CSP) hướng dẫn các tác nhân người dùng xử lý tất cả các URL không an toàn của trang web (được cung cấp qua HTTP) như thể chúng đã được thay thế bằng các URL an toàn (được cung cấp qua HTTPS). Lệnh này dành cho các trang web có số lượng lớn các URL kế thừa không an toàn cần phải viết lại.

Chỉ thị yêu cầu nâng cấp-không an toàn được đánh giá trước khi chặn toàn bộ nội dung và nếu nó được đặt, thì lệnh này thực sự là một lệnh không hoạt động. Nên đặt một chỉ thị này hoặc chỉ thị khác, nhưng không phải cả hai.

Chỉ thị yêu cầu nâng cấp không an toàn sẽ không đảm bảo rằng người dùng truy cập trang web của bạn thông qua các liên kết trên trang web của bên thứ ba sẽ được nâng cấp lên HTTPS cho điều hướng cấp cao nhất và do đó không thay thế tiêu đề Strict-Transport-Security (HSTS), mà vẫn nên được đặt với độ tuổi tối đa phù hợp để đảm bảo rằng người dùng không phải chịu các cuộc tấn công tước SSL.

Nguồn: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upTHER-insecure-requests