احتفظ بالبيانات المخزَّنة بعد ردّ 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 الثانية.