ฉันส่งคำขอ POST ไปยังเว็บไซต์ HTTP (ที่ไม่ใช่ HTTPS) ตรวจสอบคำขอในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome และพบว่ามันเพิ่มส่วนหัวของตัวเองก่อนที่จะส่งไปยังเซิร์ฟเวอร์:

Upgrade-Insecure-Requests: 1

หลังจากทำการค้นหาUpgrade-Insecure-Requestsฉันสามารถค้นหาข้อมูลเกี่ยวกับเซิร์ฟเวอร์ที่ส่งหัวข้อนี้เท่านั้น :

Content-Security-Policy: upgrade-insecure-requests

นี้ดูเหมือนว่าเกี่ยวข้อง แต่ก็ยังแตกต่างกันมากเนื่องจากในกรณีของลูกค้าจะส่งส่วนหัวในการขอใช้บริการในขณะที่ข้อมูลทั้งหมดที่ฉันได้พบคือเกี่ยวกับ SERVER ส่งส่วนหัวที่เกี่ยวข้องในการตอบสนอง

แล้วเหตุใด Chrome จึงเพิ่มUpgrade-Insecure-Requestsการร้องขอของฉันและทำอะไรได้บ้าง(44.0.2403.130 m)

อัพเดท 2016-08-24:

ส่วนหัวนี้ได้รับการเพิ่มเป็นคำแนะนำผู้สมัคร W3Cและขณะนี้ได้รับการยอมรับอย่างเป็นทางการ

สำหรับผู้ที่เพิ่งเจอคำถามนี้และสับสนคำตอบที่ดีโดย Simon East อธิบายได้ดี

Upgrade-Insecure-Requests: 1ส่วนหัวที่ใช้จะเป็นHTTPS: 1 ในร่าง W3C ทำงานก่อนหน้านี้และได้เปลี่ยนชื่อเป็นอย่างเงียบ ๆโดย Chrome ก่อนการเปลี่ยนแปลงกลายเป็นที่ยอมรับอย่างเป็นทางการ

(คำถามนี้ถูกถามในระหว่างการเปลี่ยนแปลงนี้เมื่อไม่มีเอกสารอย่างเป็นทางการเกี่ยวกับส่วนหัวนี้และ Chrome เป็นเบราว์เซอร์เดียวที่ส่งส่วนหัวนี้)

คำตอบสั้น ๆ : มันเกี่ยวข้องกับContent-Security-Policy: upgrade-insecure-requestsส่วนหัวของการตอบสนองอย่างใกล้ชิดซึ่งแสดงว่าเบราว์เซอร์รองรับ (และในความเป็นจริงก็ชอบ)

ฉันใช้เวลา 30 นาทีจาก Googling แต่ในที่สุดฉันก็พบว่ามันถูกฝังไว้ในข้อมูลจำเพาะของ W3

ความสับสนเกิดขึ้นเพราะส่วนหัวในสเปคคือHTTPS: 1และนี่คือวิธีที่ Chromium นำมาใช้ แต่หลังจากนี้ได้ทำลายเว็บไซต์จำนวนมากที่มีรหัสไม่ดี (โดยเฉพาะ WordPress และ WooCommerce) ทีม Chromium ขอโทษ:

"ฉันขอโทษสำหรับความแตกแยกที่เห็นได้ชัดว่าฉันประเมินผลกระทบต่ำกว่าความคิดเห็นบนพื้นฐานของข้อเสนอแนะระหว่าง dev และเบต้า"
- Mike West ในChrome ฉบับที่ 501842

การแก้ไขของพวกเขาคือการเปลี่ยนชื่อเป็นUpgrade-Insecure-Requests: 1และข้อมูลจำเพาะได้รับการอัปเดตให้ตรงกัน

อย่างไรก็ตามนี่คือคำอธิบายจากข้อมูลจำเพาะของ W3 (ตามที่ปรากฏในขณะนั้น) ...

HTTPSฟิลด์ส่วนหัวคำขอ HTTP ส่งสัญญาณไปยังเซิร์ฟเวอร์แสดงการตั้งค่าของลูกค้าสำหรับการตอบสนองการเข้ารหัสและรับรองความถูกต้องและที่มันประสบความสำเร็จสามารถจัดการกับการอัพเกรดที่ไม่ปลอดภัยคำขอสั่งเพื่อที่จะทำให้การตั้งค่าที่เป็นอย่างราบรื่นที่สุดเพื่อให้

...

เมื่อเซิร์ฟเวอร์พบการตั้งค่านี้ในส่วนหัวของคำขอ HTTP นั้น SHOULD จะเปลี่ยนเส้นทางผู้ใช้ไปยังการแสดงทรัพยากรที่ร้องขออย่างปลอดภัย

เมื่อเซิร์ฟเวอร์พบการตั้งค่านี้ในส่วนหัวของคำขอ HTTPS มันควรมีStrict-Transport-Securityส่วนหัวในการตอบสนองหากโฮสต์ของคำขอเป็น HSTS ปลอดภัยหรือ HSTS ปลอดภัยตามเงื่อนไข [RFC6797]

สิ่งนี้จะอธิบายทุกสิ่ง:

HTTP-Content-Security-Policy (CSP) upgrade-insecure-ร้องขอคำสั่งสั่งให้ตัวแทนผู้ใช้ปฏิบัติต่อ URL ที่ไม่ปลอดภัยทั้งหมดของเว็บไซต์ (ที่ให้บริการผ่าน HTTP) ราวกับว่าพวกเขาถูกแทนที่ด้วย URL ที่ปลอดภัย (ที่ให้บริการผ่าน HTTPS) คำสั่งนี้มีไว้สำหรับเว็บไซต์ที่มี URL ดั้งเดิมที่ไม่ปลอดภัยจำนวนมากซึ่งจำเป็นต้องเขียนใหม่

คำสั่งอัพเกรดคำขอที่ไม่ปลอดภัยได้รับการประเมินก่อนที่จะมีการบล็อกเนื้อหาแบบผสมทั้งหมดและหากมีการตั้งค่าเนื้อหาเหล่านั้นจะไม่มีประสิทธิภาพ ขอแนะนำให้ตั้งหนึ่งคำสั่งหรืออื่น ๆ แต่ไม่ใช่ทั้งสองอย่าง

คำสั่งร้องขอการอัพเกรดที่ไม่ปลอดภัยจะไม่รับรองว่าผู้ใช้ที่เข้าชมเว็บไซต์ของคุณผ่านลิงก์ในเว็บไซต์บุคคลที่สามจะได้รับการอัพเกรดเป็น HTTPS สำหรับการนำทางระดับบนสุดดังนั้นจึงไม่ได้เปลี่ยนส่วนหัวของ Strict-Transport-Security (HSTS) ซึ่ง ควรตั้งค่าอายุการใช้งานที่เหมาะสมเพื่อให้แน่ใจว่าผู้ใช้ไม่ต้องถูกโจมตีด้วยการปอก SSL

ที่มา: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests