د ډیبګینګ پراکسي سره د ناکامۍ قضیې ډیزاینول

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

«غوښتنه ناکامه شوه» ډېره پراخه ازموینه قضیه ده. یو سم د HTTP خطا ځواب، هغه ځواب چې هیڅکله نه رسیږي او یو تړاو چې د ډاونلوډ په منځ کې پرې کیږي، له اپلیکیشن څخه بېلابېل شیان غواړي.

په سمه طبقه کې مداخله وکاروئ

Charles داسې د ماتې نقطې وړاندې کوي چې غوښتنه یا ځواب د لیږلو دمخه ودروي. نیول شوی پیغام کولای شي وڅیړل شي، سم شي، تیر شي یا لغوه شي. د دوی Rewrite وسیله د ورته سرلیکونو، URLونو یا بدنونو باندې تکراریدونکي بدلونونه پلي کوي. محدودیت د بینډ ویت او اضافه شوې ځنډ کنټرولوي.

دا کنټرولونه کولای شي د HTTP کلاینټ چلند وازموي، خو د بینډ ویت حد د تصادفي IP پاکټ ضایع کیدو دقیق ماډل نه دی. پراکسي کولای شي معلومات بفر کړي، تړاوونه بیا وکاروي او جلا پورتنۍ تړاو پرانیزي. کله چې اړین حالت په ځانګړي توګه د HTTP لاندې وي، د شبکې کمزوري کولو وسیله وټاکئ.

هره قضیه د تفسیر وړ وساتئ

په پام کې نیول شوی کوربه او لار په نرۍ توګه سره سم کړئ. د عادي تبادلې سره پیل وکړئ، یو بدلون فعال کړئ او ولیکئ چې څه بدل شول. که بیا هڅه بل پای ټکي ته ورسیږي، پریکړه وکړئ چې ایا هغه قاعده باید پر هغې هڅې هم اغیزه وکړي. که نه، بې شرطه بیا لیکل کولای شي هرهه بیا رغونه لار په اصلي ناکامۍ بدله کړي.

په اپلوډ یا د تادیې په څیر عملیات کې، ورک شوی ځواب نه ثابتوي چې سرور غوښتنه رد کړې. هغه ابهام په بیا هڅې قضیه کې شامل کړئ، پرځای د دې چې ادعا وکړئ هر ترانسپورتي ناکامي د تکرار لپاره خوندي ده.

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