HTTP CONNECT উত্তর সীমার পর বাফার করা ডেটা সংরক্ষণ করুন

ছোট একটি প্রক্সি মোড়ক HTTPS-এ কাজ করে, তারপর এমন প্রোটোকলে পুনরায় ব্যবহার করলে আটকে যেতে পারে যেখানে সার্ভার আগে কথা বলে। সন্দেহজনক লাইনটি প্রায়ই সেইটি, যা গ্রহণ বাফারকে \r\n\r\n দিয়ে শেষ হওয়ার জন্য অপেক্ষা করে।

TCP ক্লায়েন্টকে একটি স্ট্রিম দেয়। একটি গ্রহণ কল HTTP স্টেটাস লাইনের অর্ধেক, সম্পূর্ণ CONNECT উত্তর, বা সেই উত্তর ও সঙ্গে সঙ্গে টানেল ডেটা ফেরত দিতে পারে। পাঠ হেডারের শেষে থামবে এমন কোনো প্রতিশ্রুতি নেই।

বাফারের ভিতরে সীমানা খুঁজুন

HTTP/1.1 CONNECT বিনিময়ের জন্য হেডার টার্মিনেটর বাফারের যেকোনো স্থানে না আসা পর্যন্ত বাইট জমা করুন। প্রথম উপস্থিতিতে ভাগ করুন। প্রথম অংশ থেকে স্টেটাস লাইন ও হেডার বিশ্লেষণ করুন; সীমানার পরের সব আলাদা রাখুন। অপেক্ষার সময় হেডার আকারের সীমা ও সময়সীমা প্রয়োগ করুন, আর খালি সকেট পাঠকে বন্ধ সংযোগ ধরে নিন, লুপের নতুন আমন্ত্রণ নয়।

শেষ সফল 2xx উত্তর সেই হেডারগুলোর ঠিক পরেই সংযোগটিকে টানেল মোডে বদলে দেয়। এর পরের বাইট ইতিমধ্যে টানেল বাইট। সেগুলো ফেলবেন না, CONNECT উত্তরের বডির জন্য অপেক্ষা করবেন না, আর Content-Length ফিল্ডকে নতুন প্রোটোকলের অংশ খরচের অনুমতি হিসেবে ব্যাখ্যা করবেন না। তথ্যমূলক উত্তর থাকলে শেষ উত্তরের আগেই সেগুলো সামলাতে হবে।

মোড়ককে তার অবশিষ্টাংশ পাঠাতে হবে

শুধু অন্তর্নিহিত সকেট ফেরত দিলে হ্যান্ডশেক বিশ্লেষক যে বাইট ইতিমধ্যে বের করেছে তা হারায়। পরের পাঠকের এমন বাফারযুক্ত স্ট্রিম দরকার যা আগে সংরক্ষিত লেজ দেয়, তারপর সকেট পাঠ চালু করে। সার্ভার-প্রথম প্রোটোকলে সেই প্রাথমিক অভিবাদন হারানো দুই পক্ষকে অনির্দিষ্টকাল অপেক্ষা করাতে পারে।

বিপরীতভাবে, ব্যর্থ CONNECT উত্তর থেকে আসা বাইট টানেল অভিবাদন নয়। 407 এখনও প্রক্সি বিনিময়ের অংশ এবং প্রমাণীকরণ সামলানো দরকার; অন্য অ-সফল স্টেটাসের জন্য উপযুক্ত ত্রুটি পথ দরকার।

এটি বিশেষভাবে গুরুত্বপূর্ণ যখন HTTP প্রক্সির মাধ্যমে FTP বা SSH ক্লায়েন্ট অভিযোজিত হয়। প্রক্সিকে অনুরোধ করা গন্তব্য পোর্টও অনুমোদন করতে হয়, আর FTP-র অতিরিক্ত ডেটা সংযোগ লাগতে পারে। সঠিক হেডার বিশ্লেষণ স্ট্রিম হস্তান্তর সমাধান করে; এটি CONNECT অনুমতি দিতে বা FTP-র দ্বিতীয় চ্যানেল যোগাতে পারে না।