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 کا دوسرا چینل فراہم کر سکتی ہے۔