طراحی موارد خطا با یک پروکسی اشکال‌زدایی

پروکسی اشکال‌زدایی زمانی سودمند است که کلاینت باید با پاسخی روبه‌رو شود که سرور عادی به‌ندرت تولید می‌کند. ابتدا رفتار کلاینت را تعریف کنید، سپس مداخله‌ای را انتخاب کنید که آن شرایط را پدید می‌آورد.

«درخواست ناموفق بود» یک مورد آزمون بیش از حد کلی است. یک پاسخ خطای معتبر HTTP، پاسخی که هرگز نمی‌رسد و اتصالی که در میانهٔ یک دانلود قطع می‌شود، چیزهای متفاوتی از برنامه می‌خواهند.

از مداخله در لایهٔ درست استفاده کنید

Charles نقاط توقفی ارائه می‌دهد که یک درخواست یا پاسخ را پیش از ارسال متوقف می‌کنند. پیام رهگیری‌شده را می‌توان بررسی و ویرایش کرد، اجازهٔ عبور داد یا لغو کرد. ابزار Rewrite آن تغییرات تکرارشدنی را بر سرصفحه‌ها، نشانی‌های URL یا بدنه‌های منطبق اعمال می‌کند. محدودسازی، پهنای باند و تأخیر افزوده را کنترل می‌کند.

این کنترل‌ها می‌توانند رفتار یک کلاینت HTTP را بیازمایند، اما محدودیت پهنای باند مدل دقیقی از افت تصادفی بستهٔ IP نیست. یک پروکسی می‌تواند داده را بافر کند، اتصال‌ها را بازاستفاده کند و اتصال جداگانه‌ای به بالادست باز کند. وقتی شرایط لازم مشخصاً زیر HTTP است، ابزار تضعیف شبکه را انتخاب کنید.

هر مورد را قابل تفسیر نگه دارید

میزبان و مسیر موردنظر را به‌طور باریک تطبیق دهید. با یک تبادل معمولی آغاز کنید، یک تغییر را فعال کنید و ثبت کنید چه چیزی تغییر کرده است. اگر یک تلاش دوباره به نقطهٔ پایانی دومی برسد، تصمیم بگیرید آیا همان قاعده باید بر آن تلاش اثر بگذارد. در غیر این صورت بازنویسی بی‌قید می‌تواند هر مسیر بازیابی را به همان خطای اولیه تبدیل کند.

در یک بارگذاری یا عملیات شبیه پرداخت، پاسخ گم‌شده ثابت نمی‌کند که سرور درخواست را رد کرده است. این ابهام را در مورد تلاش دوباره بگنجانید، به‌جای آنکه ادعا کنید هر خطای انتقال برای تکرار ایمن است.

بررسی یا ویرایش محتوای HTTPS مستلزم آن است که کلاینت در پیکربندی بازرسی TLS پروکسی اشکال‌زدایی مشارکت کند. پروکسی‌ای که فقط CONNECT را حمل می‌کند، بایت‌های رمزنگاری‌شدهٔ برنامه را می‌بیند. از پیکربندی آزمون جداگانه استفاده کنید و پس از آن مسیریابی و تنظیمات اعتماد آن را بازگردانید تا مشاهدات بعدی کلاینت عادی را توصیف کنند.