مهلات CONNECT عبر البروكسي بعد نجاح اتصال TCP
حدِّد المهلة النشطة أثناء CONNECT بدلًا من افتراض أن اتصال TCP المكتمل أنهى أيضًا إعداد النفق.
لقد أدى مهلة اتصال TCP مهمتها بمجرد أن يتصل العميل بالبروكسي. أما الانتظار التالي—استلام رد CONNECT كامل—فقد يحكمه مؤقّت مختلف.
قد يكون البروكسي ما زال يتصل بالخادم الأعلى، أو يتبادل رسائل المصادقة، أو ينتظر خدمة أخرى. ولم يبدأ بعد الرد العادي للموقع.
| آخر خطوة مكتملة | ما الذي ما زال منتظرًا؟ |
|---|---|
| تم اتصال TCP بالبروكسي | مصافحة البروكسي، بما في ذلك قبول CONNECT |
| تم قبول CONNECT | TLS الوجهة، عندما يستخدمه الهدف |
| أُرسل طلب الوجهة | رد الوجهة |
ابحث عن المؤقّت النشط بينما يقرأ الموصّل تلك المصافحة ويكتبها. وقد لا تدخل خاصية تُسمّى “response timeout” حيّز التنفيذ إلا بعد إنشاء المسار. مع HttpClient 5، ميّز بين ConnectionConfig ومهلة المقبس الخاصة به، وإعداد مصافحة TLS، ومهلة الاستجابة على مستوى الطلب. طبّق إعداد الاتصال ذا الصلة عبر المدير الذي يستخدمه العميل الفعلي. تستخدم أجيال Apache HttpClient القديمة واجهات مختلفة، لذا لا تُعدّ القصاصة الأقدم خريطة موثوقة لهذه المسؤوليات.
أبقِ رفض CONNECT النهائي بوصفه ردًّا من البروكسي. أما الرد الناجح الذي يعقبه توقف TLS فهو مرحلة فشل أخرى. وعبارة “اتصال TCP قائم؛ لا رد CONNECT كامل قبل الموعد النهائي للإعداد” تصف المشكلة بدقة أكبر من وصف عام لمهلة البروكسي.
يمكن أن موعدًا نهائيًا إجماليًا أن يحدّ انتظار المستدعي إلى جانب حدود المراحل هذه. وعندما ينتهي، ألغِ العملية أو أغلقها عبر دورة الحياة التي يدعمها العميل قبل أن يستهلك محاولة أخرى سعة الاتصال.