یو اضافي نوی کرښه کولی شي د CONNECT وروسته TLS مات کړي

کله چې CONNECT 200 بیرته راولي او TLS سمدلاسه نشي کوډ کولی، د سندونو یا سایفرونو بدلولو دمخه په نښلونکې کې د پولې بایټونه وګورئ.

جوړ شوی اجازه ارزښت ممکن لا دمخه د نوي کرښې سره پای ته ورسیږي. بله کرښې پایه اضافه کول کولی شي HTTP سرلیکونه ژر پای ته ورسوي، او غوښتل شوی Host ساحه یا بل ساده متن د غوښتنې شاته پرېږدي.

لږترلږه HTTP/1.1 CONNECT غوښتنه د کرښو ترمنځ CRLF او په پای کې تشه کرښه کاروي:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

هره اجازه ساحه د دې وروستي تشې کرښې دمخه ځای پرځای کړئ، پرته له دننه کرښې ماتیدو. په Python کې "\n" نوې کرښه ښیې؛ هغه خام سټرنګ چې بیک سلیش او n توري لري نه. د لرې کولو هڅه کولو دمخه وګورئ چې د کوډ کولو مرستندوی کوم بایټونه جوړوي—زوړ مرستندویان کولی شول کرښې ماتې اضافه کړي.

کله چې CONNECT بریالی شي، هغه پاتې بایټونه د تونل پروتوکول دي. ورک شوی ساده متن کولی شي TLS ته انتظار کوونکي ملګري ته ورسیږي. بریالۍ حالت نشي کولی هغه بایټونه سم کړي چې د ناسمې غوښتنې وروسته لا دمخه په قطار کې دي.

د ترلاسه کولو پوله هم وګورئ. د ساکټ TLS ته سپارلو دمخه بشپړ پروکسي ځواب ولولئ، جزوي لوستل اداره کړئ او هر هغه څه وساتئ چې د سرلیکونو هاخوا لوستل کیږي. یو ساکټ لوستل اړینه نه ده چې یو بشپړ پیغام ولري.

که دا تحلیل کوونکی ستاسو دی، د سم شوي بایټ استازیتوب د تار ګرامر سره پرتله کړئ؛ پټنوم پټولو په حال کې اوږدوالی او کرښې پولې ښکاره وساتئ. د هغې اپلیکیشن لپاره چې یوازې پروکسي اړیکې ته اړتیا لري، ساتل شوی نښلونکی د دې چوکاټ کوډ درلودلو اړتیا مخنیوی کوي.