2
Transfer-Encoding: gzip เทียบกับ Content-Encoding: gzip
สถานการณ์ปัจจุบันเป็นอย่างไรเมื่อต้องทำ Transfer-Encoding: gzip หรือก Content-Encoding: gzip เมื่อฉันต้องการที่จะช่วยให้ลูกค้าด้วยเช่นแบนด์วิดธ์ที่ จำกัด ในการส่งสัญญาณของพวกเขาเต็มใจที่จะยอมรับการตอบสนองที่ถูกบีบอัดและเซิร์ฟเวอร์มีสุดท้ายกล่าวหรือไม่ที่จะบีบอัด อย่างหลังคือสิ่งที่เช่น mod_deflate ของ Apache และ IIS ทำถ้าคุณปล่อยให้มันดูแลการบีบอัด Transfer-Encoding: chunkedขึ้นอยู่กับขนาดของเนื้อหาที่ถูกบีบอัดก็จะทำเพิ่มเติม นอกจากนี้ยังรวมถึง a Vary: Accept-Encodingซึ่งบอกใบ้ถึงปัญหาแล้ว Content-Encodingดูเหมือนว่าจะเป็นส่วนหนึ่งของเอนทิตีดังนั้นการเปลี่ยนContent-Encodingจำนวนเงินเป็นการเปลี่ยนแปลงของเอนทิตีกล่าวคือAccept-Encodingส่วนหัวที่แตกต่างกันเช่นแคชไม่สามารถใช้เอนทิตีที่เหมือนกันในเวอร์ชันแคช มีคำตอบที่ชัดเจนเกี่ยวกับสิ่งนี้หรือไม่ที่ฉันพลาดไป (และไม่ได้ฝังอยู่ในข้อความในเธรดยาว ๆ ในกลุ่มข่าว apache บางกลุ่ม) ความประทับใจในปัจจุบันของฉันคือ: ในความเป็นจริงแล้วการโอนการเข้ารหัสเป็นวิธีที่ถูกต้องในการทำสิ่งที่ส่วนใหญ่ทำกับการเข้ารหัสเนื้อหาโดยการใช้เซิร์ฟเวอร์และไคลเอ็นต์ที่มีอยู่ การเข้ารหัสเนื้อหาเนื่องจากผลกระทบทางความหมายทำให้เกิดปัญหาสองสามประการ (เซิร์ฟเวอร์ควรทำอย่างไรETagเมื่อบีบอัดการตอบกลับอย่างโปร่งใส) เหตุผลก็คือ chicken'n'egg: เบราว์เซอร์ไม่รองรับเนื่องจากเซิร์ฟเวอร์ไม่รองรับเนื่องจากเบราว์เซอร์ไม่รองรับ ดังนั้นฉันคิดว่าวิธีที่ถูกต้องน่าจะเป็นTransfer-Encoding: gzip(หรือถ้าฉันรวมร่างเป็นก้อนมากขึ้นมันก็จะกลายเป็น Transfer-Encoding: gzip, chunked ) และไม่มีเหตุผลที่จะแตะต้องVaryหรือETagหรือส่วนหัวอื่นใดในกรณีนั้นเนื่องจากเป็นสิ่งที่มีระดับการขนส่ง สำหรับตอนนี้ฉันไม่สนใจมากเกินไปเกี่ยวกับ 'hop-by-hop'-ness ของTransfer-Encodingสิ่งที่คนอื่นดูเหมือนจะกังวลเป็นอันดับแรกและสำคัญที่สุดเพราะพร็อกซีอาจคลายการบีบอัดและส่งต่อโดยไม่บีบอัดไปยังไคลเอนต์ อย่างไรก็ตามพร็อกซีอาจส่งต่อตามที่เป็นอยู่ (บีบอัด) ได้เช่นกันหากคำขอเดิมมีAccept-Encodingส่วนหัวที่เหมาะสมซึ่งในกรณีของเบราว์เซอร์ทั้งหมดที่ฉันรู้ว่าเป็นที่กำหนด Btw …