ڈیبگنگ پراکسی کے ساتھ ناکامی کے کیسز ڈیزائن کرنا

ڈیبگنگ پراکسی اس وقت مفید ہوتی ہے جب کلائنٹ کو ایسا جواب ملنا ہو جو عام سرور شاذ و نادر ہی پیدا کرتا ہے۔ پہلے کلائنٹ کے رویے کی وضاحت کریں، پھر وہ مداخلت منتخب کریں جو وہ حالت پیدا کرتی ہے۔

«درخواست ناکام ہو گئی» بہت وسیع ٹیسٹ کیس ہے۔ درست HTTP غلطی کا جواب، ایسا جواب جو کبھی نہ آئے اور ڈاؤن لوڈ کے درمیان منقطع کنکشن ایپلیکیشن سے مختلف چیزیں مانگتے ہیں۔

درست پرت پر مداخلت استعمال کریں

Charles ایسے بریک پوائنٹس دیتا ہے جو درخواست یا جواب کو آگے بھیجنے سے پہلے روک دیتے ہیں۔ روکی گئی پیغام کی جانچ اور ترمیم کی جا سکتی ہے، گزرنے دیا جا سکتا ہے یا منسوخ کیا جا سکتا ہے۔ اس کا Rewrite ٹول مماثل ہیڈرز، URLs یا باڈیز پر دہرائی جانے والی تبدیلیاں لاگو کرتا ہے۔ تھروٹلنگ بینڈوڈتھ اور اضافی تاخیر کو کنٹرول کرتی ہے۔

یہ کنٹرولز HTTP کلائنٹ کے رویے کی جانچ کر سکتے ہیں، لیکن بینڈوڈتھ کی حد بے ترتیب IP پیکٹ ضیاع کا درست ماڈل نہیں ہے۔ پراکسی ڈیٹا بفر کر سکتی ہے، کنکشن دوبارہ استعمال کر سکتی ہے اور الگ اپ اسٹریم کنکشن کھول سکتی ہے۔ جب مطلوبہ حالت خاص طور پر HTTP سے نیچے ہو تو نیٹ ورک کمزور کرنے کا ٹول منتخب کریں۔

ہر کیس کو قابلِ تشریح رکھیں

مطلوبہ میزبان اور راستہ تنگ طور پر ملائیں۔ معمول کے تبادلے سے شروع کریں، ایک تبدیلی فعال کریں اور لکھیں کہ کیا بدلا۔ اگر دوبارہ کوشش دوسرے اینڈ پوائنٹ تک پہنچے تو فیصلہ کریں کہ کیا وہی قاعدہ اس کوشش پر بھی لاگو ہونا چاہیے۔ بصورت دیگر بلا شرط دوبارہ تحریر ہر بحالی راستے کو اصل ناکامی میں بدل سکتی ہے۔

اپ لوڈ یا ادائیگی جیسی کارروائی میں، گم شدہ جواب یہ ثابت نہیں کرتا کہ سرور نے درخواست مسترد کی۔ ہر ٹرانسپورٹ ناکامی کو دہرانا محفوظ ہے—یہ دعویٰ کرنے کے بجائے اس ابہام کو دوبارہ کوشش کے کیس میں شامل کریں۔

HTTPS مواد کی جانچ یا ترمیم کے لیے کلائنٹ کو ڈیبگنگ پراکسی کے TLS معائنہ سیٹ اپ میں حصہ لینا ہوتا ہے۔ صرف CONNECT لے جانے والی پراکسی خفیہ کردہ ایپلیکیشن بائٹس دیکھتی ہے۔ الگ جانچ کنفیگریشن استعمال کریں اور بعد میں اس کی روٹنگ اور اعتماد کی ترتیبات بحال کریں، تاکہ بعد کے مشاہدات عام کلائنٹ کو بیان کریں۔