เมื่อไฟล์ที่ดาวน์โหลดเริ่มต้นด้วยบรรทัดสถานะ HTTP

ถ้าไฟล์ที่คิดว่าเป็น PDF หรือสเปรดชีตเริ่มต้นด้วย HTTP/1.1 200 OK แสดงว่าตัวดาวน์โหลดบันทึกคำตอบดิบแทนที่จะเป็นไฟล์จริง คำตอบแบบแผนผังนี้มีเนื้อหาเพียงสี่ไบต์:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

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

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

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

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

HTTPS ต้องการมากกว่าการตัดคำตอบ CONNECT ออก: หลังจากตั้งอุโมงค์สำเร็จแล้ว ต้องสร้าง TLS ไปยังปลายทางแล้วจึงแยกวิเคราะห์คำตอบ HTTP ภายใน ไบต์ที่เข้ารหัสหลังเฮดเดอร์ของพร็อกซีไม่ใช่ไฟล์ที่ดาวน์โหลดได้

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