TCP সংযোগ সফল হওয়ার পরে প্রক্সি CONNECT সময়সীমা
সম্পূর্ণ TCP সংযোগ টানেল সেটআপও শেষ করেছে বলে ধরে নেওয়ার বদলে CONNECT চলাকালে সক্রিয় সময়সীমাটি শনাক্ত করুন।
ক্লায়েন্ট প্রক্সির সাথে সংযুক্ত হওয়ামাত্র একটি TCP সংযোগ সময়সীমা তার কাজ শেষ করেছে। পরের অপেক্ষা—সম্পূর্ণ CONNECT উত্তর পাওয়া—অন্য একটি টাইমার দ্বারা নিয়ন্ত্রিত হতে পারে।
প্রক্সি হয়তো এখনও আপস্ট্রিমে সংযুক্ত হচ্ছে, প্রমাণীকরণ বার্তা বিনিময় করছে বা অন্য কোনো পরিষেবার জন্য অপেক্ষা করছে। ওয়েবসাইটের স্বাভাবিক উত্তর এখনও শুরু হয়নি।
| শেষ সম্পন্ন ধাপ | এখনও কীসের অপেক্ষা? |
|---|---|
| প্রক্সির সাথে TCP সংযুক্ত | প্রক্সি হ্যান্ডশেক, CONNECT গ্রহণসহ |
| CONNECT গৃহীত | গন্তব্যের TLS, যখন লক্ষ্য এটি ব্যবহার করে |
| গন্তব্য অনুরোধ পাঠানো হয়েছে | গন্তব্যের উত্তর |
কানেক্টর যখন সেই হ্যান্ডশেক পড়ে ও লেখে তখন কোন টাইমার সক্রিয় তা খুঁজে বের করুন। “response timeout” নামের একটি বৈশিষ্ট্য হয়তো রুট প্রতিষ্ঠার পরেই কার্যকর হয়। HttpClient 5-এ ConnectionConfig এবং এর সকেট সময়সীমা, TLS হ্যান্ডশেক কনফিগারেশন ও অনুরোধ-স্তরের প্রতিক্রিয়া সময়সীমার মধ্যে পার্থক্য করুন। প্রাসঙ্গিক সংযোগ কনফিগারেশনটি প্রকৃত ক্লায়েন্ট যে ম্যানেজার ব্যবহার করে তার মাধ্যমে প্রয়োগ করুন। পুরোনো Apache HttpClient প্রজন্ম ভিন্ন API ব্যবহার করে, তাই পুরোনো স্নিপেট এই দায়িত্বগুলোর নির্ভরযোগ্য মানচিত্র নয়।
চূড়ান্ত CONNECT প্রত্যাখ্যানকে প্রক্সির উত্তর হিসেবে ধরে রাখুন। সফল উত্তর के পরেও TLS থেমে যাওয়া আরেকটি ব্যর্থতার স্তর। “TCP সংযুক্ত; সেটআপ সময়সীমার আগে সম্পূর্ণ CONNECT উত্তর নেই” কথাটি সাধারণ প্রক্সি সময়সীমার চেয়ে সমস্যাটিকে আরও নিখুঁতভাবে বর্ণনা করে।
একটি সামগ্রিক সময়সীমা এই ধাপ-সীমাগুলোর সাথে কলারের অপেক্ষাকে সীমাবদ্ধ করতে পারে। এটি শেষ হলে, আরেকটি চেষ্টা সংযোগ ক্ষমতা না নেওয়ার আগে ক্লায়েন্টের সমর্থিত লাইফসাইকেলের মাধ্যমে অপারেশনটি বাতিল করুন বা বন্ধ করুন।