การอ่านไฟล์อัปโหลดทีละส่วนไม่จำเป็นต้องใช้ Chunked HTTP

ไม่ใช่ ไคลเอนต์สามารถอ่านไฟล์ขนาดใหญ่ในบัฟเฟอร์เล็ก ๆ และส่งด้วย Content-Length ที่ทราบค่าได้ การอ่านแบบมีขอบเขตควบคุมการใช้หน่วยความจำ ส่วนการจัดเฟรม HTTP บอกผู้รับว่าบอดี้ของคำขอสิ้นสุดที่ใด

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

สำหรับ HTTP/1.1 ให้ตรวจดูการจัดเฟรมที่ส่งจริง: Content-Length หรือ chunked transfer coding ตามกฎของโปรโตคอล การเข้ารหัสแบบ chunked เพิ่มเครื่องหมายขนาดภายนอกเนื้อหาไฟล์ อย่ารวมฟิลด์การจัดเฟรมที่ขัดแย้งกัน และอย่าเดาความยาวเพื่อให้พร็อกซียอมรับการอัปโหลด

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

เส้นทางมีผลต่อการสังเกตนั้น การส่งต่อแบบข้อความธรรมดาเปิดเผยการจัดเฟรม HTTP ของการอัปโหลดให้พร็อกซีเห็น ส่วน HTTPS แบบ end-to-end ทั่วไปวางไว้ในอุโมงค์ HTTP/2 ใช้การจัดเฟรมของตัวเอง ดังนั้นข้อจำกัดในอดีตของ Squid จึงอธิบายความล้มเหลวเก่า ๆ บางกรณี ไม่ใช่กฎที่พร็อกซีปัจจุบันทุกตัวปฏิเสธการอัปโหลดแบบสตรีม