د 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 دوهمه کانال برابره کړي.