انتظر السطر الفارغ بعد CONNECT

يرى العميل 200 Connection Established فيبدأ TLS فورًا، ثم يعرض كلامًا بلا معنى حيث يجب أن يكون سجل TLS. ابحث عن استجابة HTTP غير مكتملة قبل أن تلوم إعدادات التشفير في الوجهة.

في تبادل HTTP/1 CONNECT، سطر الحالة ليس إلا بداية الاستجابة؛ فقد تتبعه حقول ترويسة. السطر الفارغ الذي ينهي قسم الترويسة يعلن الانتقال إلى النفق بعد استجابة CONNECT ناجحة.

HTTP/1.1 200 Connection Established\r\n
Proxy-Agent: example\r\n
\r\n

قد تصل هذه البايتات في قراءة واحدة أو عدة قراءات أو قراءة تحمل بايتات لاحقة أيضًا. فـ TCP لا يحافظ على حدود الكتابة لدى الخادم.

اجعل التسليم حالة صريحة في المحلّل

1. اجمع سطر الحالة وحلّله. استخدم الرمز الرقمي بدل عبارة السبب الإنجليزية الحرفية.
2. واصل حتى يصل منهي قسم الترويسة كاملًا. فنجاح سطر الحالة لا يجعل الحقول المتبقية تختفي.
3. في استجابة CONNECT الناجحة، اعتبر البايت الذي يلي المنهي مباشرة بداية بيانات النفق. وفي الاستجابات الأخرى اتبع معالجة استجابة HTTP والمصادقة المناسبة.
4. انقل الاتصال وأي بايتات غير مستهلكة عبر واجهة الإدخال/الإخراج المخزّنة التي يدعمها البروتوكول التالي.

الخطوة الأخيرة مهمة حتى مع بحث جيد عن الفاصل. فقد يكون القارئ المخزّن قد استهلك من المقبس أكثر مما طلبه المحلّل. وبدء TLS على المقبس العاري مع هجر ذلك القارئ قد يترك بايتات عالقة في مخزن القارئ الخاص.

استخدم مهلة للإعداد وحدًا لحجم الترويسة. إن EOF قبل المنهي استجابة وكيل ناقصة، وليس دعوة للانتظار إلى الأبد أو لتجربة TLS على أي حال.

فكّر في عدة حدود

تخيّل قراءة تنتهي بعد Proxy-Agent:. ما زال المحلّل يحتاج مزيدًا من بايتات ترويسة HTTP. وتخيّل قراءة أخرى تنتهي في منتصف تسلسل CRLF الأخير؛ فذلك ليس قسم ترويسة كاملًا بعد. والآن تخيّل قسم ترويسة ناجحًا كاملًا تتبعه بايتات نفق في المخزن نفسه: تلك البايتات الزائدة يجب أن تنجو من التسليم.

الاستجابة 407 نتيجة مختلفة؛ فهي تحتاج معالجة مصادقة، ولا تجيز إرسال TLS ClientHello إلى نفق لم يُفتح قط.

فضّل موصّلًا مُصانًا ما لم يكن تنفيذ المصافحة هو المهمة. هذا الحد خاص بتبادل HTTP/1 المعروض هنا. أما وكيل HTTP/2 فيحمل CONNECT على تدفق بتأطير مختلف.