เก็บข้อมูลที่บัฟเฟอร์ไว้หลังการตอบกลับ HTTP CONNECT

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

TCP ให้สตรีมกับไคลเอนต์ การเรียกอ่านครั้งเดียวอาจคืนครึ่งบรรทัดสถานะ HTTP การตอบกลับ CONNECT ที่สมบูรณ์ หรือการตอบกลับนั้นตามด้วยข้อมูลอุโมงค์ทันที ไม่มีการรับประกันว่าการอ่านจะหยุดที่จุดสิ้นสุดของส่วนหัว

หาขอบเขตภายในบัฟเฟอร์

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

การตอบกลับ 2xx ที่สำเร็จครั้งสุดท้ายจะเปลี่ยนการเชื่อมต่อเป็นโหมดอุโมงค์ทันทีหลังส่วนหัวเหล่านั้น ไบต์ที่ตามมาจึงเป็นไบต์ของอุโมงค์แล้ว อย่าทิ้ง อย่า รอเนื้อหาการตอบกลับ CONNECT และอย่าตีความฟิลด์ Content-Length ว่าเป็นสิทธิ์ในการใช้ส่วนหนึ่งของโปรโตคอลใหม่ หากมีการตอบกลับแบบให้ข้อมูล ต้องจัดการก่อนการตอบกลับสุดท้ายนั้น

ตัวห่อต้องส่งต่อสิ่งที่เหลืออยู่

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

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

เรื่องนี้สำคัญเป็นพิเศษเมื่อปรับไคลเอนต์ FTP หรือ SSH ให้ทำงานผ่านพร็อกซี HTTP พร็อกซียังต้องอนุญาตพอร์ตปลายทางที่ร้องขอ และ FTP อาจต้องใช้การเชื่อมต่อข้อมูลเพิ่มเติม การแยกวิเคราะห์ส่วนหัวที่ถูกต้องแก้ปัญหาการส่งต่อสตรีม แต่ให้สิทธิ์ CONNECT หรือจัดหาช่องทางที่สองของ FTP ไม่ได้