ข้อควรพิจารณาของ HTTP Content-MD5 Header

เรากำลังถกเถียงกันว่าจะใช้ส่วนหัวของ Content-MD5 หรือไม่

ข้อดี:

CMS ช่วยให้เราสามารถรวมกับค่าใช้จ่ายน้อยที่สุด (การตอบสนองที่แคชไว้ใน 80% + ของกรณี)
มันจะเพิ่มอีกชั้นของการป้องกันปัญหา

จุดด้อย:

ส่วนหัวความยาวเนื้อหามีอยู่เสมอ (แม้ในหน้าเว็บที่สร้างขึ้นแบบไดนามิก) ดังนั้นลูกค้าไม่ควรต้องการการตรวจสอบความถูกต้องรูปแบบอื่น
จนถึงตอนนี้เราไม่ทราบถึงปัญหาใด ๆ ที่เกิดจากการทุจริต
MD5 ตรวจสอบเพิ่มเวลาแฝงในการโหลดหน้าเว็บ

คะแนน:

สื่อบางประเภทมีรูปแบบการแยกย่อยของตนเองที่ไม่จำเป็นหรือไม่?
หาก TCP เสนอสิ่งนี้แล้วทำไมมันจึงรวมอยู่ในมาตรฐาน HTTP
สิ่งที่มีอยู่ในชีวิตจริงใช้คืออะไร?
การตรวจสอบ MD5 นั้นเล็กน้อยหรือไม่?

ไม่มีปัญหาจริงสำหรับการเพิ่มลงในการทดสอบหน่วยและใช้งานเกี่ยวกับชั่วโมงทำงาน อย่างไรก็ตามหากมันเป็นอันตรายเราต้องการให้มันเพิ่มการทดสอบสูดดมในระดับที่สูงขึ้นที่ใช้ในเว็บไซต์ "ตรวจสุขภาพ"

http http-headers headers

— Metalshark
แหล่งที่มา

TCP มีการแก้ไขข้อผิดพลาดอยู่แล้ว แต่นี่จะช่วยคุณในเลเยอร์ TCP เท่านั้น พร็อกซี HTTP ตัวกลางหรือ load balancer สามารถทำลายข้อมูลในเลเยอร์ HTTP แล้วส่งใหม่ HTTP MD5 ทำให้สามารถตรวจจับความเสียหายนี้ได้ เหตุผลที่ไม่มีใครพูดถึงความต้องการนี้อย่างแท้จริงคือปัญหานี้หายากมาก HTTP พร็อกซีส่วนใหญ่ ฯลฯ "ทำงานได้"

RFC หมายถึงความปลอดภัย IMHO สิ่งนี้อ่อนแอดังนั้นควรละเว้น - ถ้าคุณต้องการความปลอดภัยและการรักษาความลับที่แท้จริงคุณต้องใช้ HTTPS

สื่อบางประเภทมีรูปแบบการแยกย่อยของตนเองที่ไม่จำเป็นหรือไม่?

ไม่ใช่สิ่งที่ดีจริงๆ แต่ข้อผิดพลาดเล็กน้อยในภาพถ่ายวิดีโอสตรีมมิ่ง ฯลฯ มักจะมองไม่เห็นกับมนุษย์

ฉันจะบอกว่ามันขึ้นอยู่กับกรณีการใช้งาน:

สำหรับเว็บเซอร์วิสที่ใช้ REST แล้วไดเจสต์จะเพิ่มเลเยอร์ที่มีประโยชน์ของการแก้ไขข้อผิดพลาดเพิ่มเติม เห็นนี้ล้มเหลว AWS เป็นตัวอย่าง
สำหรับแอปพลิเคชันที่จัดการกับข้อมูลภารกิจสำคัญผ่าน HTTP ธรรมดามันคุ้มค่าที่จะนำไปใช้ Content-MD5 ให้ตัวเลือกแก่ลูกค้าในการตรวจสอบความสมบูรณ์ของการส่งผ่านแบบ end-to-end
สำหรับเว็บไซต์ 'ปกติ' ที่แสดงข้อความและสื่อที่มีค่า 'ปกติ' ส่วนหัวของเนื้อหา -MD5 ไม่มีจุดประสงค์ และฉันก็ไม่รู้ด้วยซ้ำว่าเบราว์เซอร์กระแสหลักจำนวนเท่าใด (พีซีโดยเฉพาะอุปกรณ์พกพา) รองรับได้จริง

— Jesper M
แหล่งที่มา

กรณีความล้มเหลวของ AWS นั้นร้ายกาจจริงๆ มันมีอายุไม่กี่ปี แต่จริง ๆ แล้วเป็นตัวอย่างที่น่าทึ่งของโหมดความล้มเหลวที่ฉันไม่เคยคิดถึง สิ่งที่น่าสนใจมากที่ควรระวังเมื่อใช้ที่เก็บข้อมูลจากระยะไกล ฉันสงสัยเกี่ยวกับโซลูชัน NoSQL บางอย่างและวิธีจัดการกับปัญหาดังกล่าว

— artlung

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

— Metalshark

นั่นขึ้นอยู่กับว่าบิตที่พลิกนั้นอยู่ที่ใด ถ้ามันเป็นบิตที่มีนัยสำคัญน้อยที่สุดมันก็จะไม่สามารถมองเห็นได้ แต่มีความแตกต่างกันมากระหว่างสีและrgb(255, 0, 0) rgb(127, 0, 0)ด้วยวิดีโอดิบความเสียหายของพิกเซลเดียวจะรับรู้ได้น้อยลงเพราะมันอยู่บนหน้าจอชั่วครู่ชั่วครู่ แต่เนื่องจากวิดีโอออนไลน์ส่วนใหญ่ใช้อัลกอริธึมการบีบอัดที่มีประสิทธิภาพสูงบิตเดียวที่ถูกพลิกอาจทำให้ครึ่งหนึ่งของภาพเสียหายหรือเลื่อนข้าม จอภาพ

— Lèsemajesté

เช่นเดียวกับที่คุณพูดธนาคารควรใช้ HTTPS ดังนั้นจึงไม่มีประเด็นที่จะใช้Content-MD5เช่นกันเนื่องจาก SSL / TLS มีข้อความสรุปที่ชั้นแอปพลิเคชันอยู่แล้ว

— Lèsemajesté

@ Lèsemajesté: เกี่ยวกับข้อผิดพลาดเล็กน้อยฉันเห็นด้วยในกรณีนามธรรม แต่โปรดจำไว้ว่าวิดีโอสตรีมมิ่ง fx ส่วนใหญ่ใช้การขนส่งเฉพาะแอปพลิเคชันผ่าน UDP หรือ TCP เพื่อให้การแลกเปลี่ยน 'ถูกต้อง' ระหว่างการแก้ไขข้อผิดพลาดและความเร็ว - และสตรีมมิ่งวิดีโอจึงไม่เป็นกรณีที่ใช้สำหรับ Content-MD5 เกี่ยวกับธนาคารควรใช้ HTTPS ฉันเห็นด้วยและฉันกำลังใช้ถ้อยคำใหม่เพื่อให้ชัดเจนยิ่งขึ้น

— Jesper M

MD5 ตรวจสอบเพิ่มเวลาแฝงในการโหลดหน้าเว็บ

หากเป็นเรื่องจริง (และความล่าช้าไม่ได้เป็นเรื่องเล็กน้อย) ฉันก็บอกว่ามันไม่คุ้มค่า

โดยทั่วไปแล้วฉันเชื่อว่าส่วนหัวที่แก้ไขล่าสุดมักใช้เพื่อกำหนดว่าหน้ามีการเปลี่ยนแปลงหรือไม่ สมมติว่าคุณให้ค่าที่มีความหมายที่นั่นฉันไม่เห็นความจำเป็นสำหรับส่วนหัว content-md5

— คริส
แหล่งที่มา