डीबगिंग प्रॉक्सीसह अपयशाची प्रकरणे रचणे

डीबगिंग प्रॉक्सी तेव्हा उपयुक्त असते जेव्हा क्लायंटला अशा प्रतिसादाचा सामना करायचा असतो जो सामान्य सर्व्हर क्वचितच तयार करतो. आधी क्लायंटचे वर्तन ठरवा, मग ती स्थिती निर्माण करणारा हस्तक्षेप निवडा.

“विनंती अयशस्वी झाली” हे खूप व्यापक चाचणी प्रकरण आहे. वैध HTTP त्रुटी प्रतिसाद, कधीही न येणारा प्रतिसाद आणि डाउनलोडच्या मध्ये तुटलेले कनेक्शन या गोष्टी अनुप्रयोगाकडून वेगवेगळ्या गोष्टी मागतात.

योग्य स्तरावर हस्तक्षेप वापरा

Charles अशा ब्रेकपॉइंट्स देतो जे विनंती किंवा प्रतिसाद पुढे पाठवण्यापूर्वी थांबवतात. अडवलेला संदेश तपासता व संपादित करता येतो, जाऊ देताता येतो किंवा रद्द करता येतो. त्याचे Rewrite साधन जुळणाऱ्या हेडर, URL किंवा बॉडीवर पुनरावृत्ती करण्यायोग्य बदल लागू करते. थ्रॉटलिंग बँडविड्थ आणि अतिरिक्त विलंब नियंत्रित करते.

ही नियंत्रणे HTTP क्लायंटचे वर्तन तपासू शकतात, पण बँडविड्थ मर्यादा यादृच्छिक IP पॅकेट हानीचे अचूक मॉडेल नाही. प्रॉक्सी डेटा बफर करू शकते, कनेक्शन पुन्हा वापरू शकते आणि वेगळे अपस्ट्रीम कनेक्शन उघडू शकते. आवश्यक स्थिती विशेषतः HTTPच्या खाली असेल तेव्हा नेटवर्क क्षय साधन निवडा.

प्रत्येक प्रकरण अर्थ लावण्यायोग्य ठेवा

इच्छित होस्ट आणि मार्ग जवळून जुळवा. सामान्य देवघेवीने सुरुवात करा, एक बदल सक्रिय करा आणि काय बदलले ते नोंदवा. पुनःप्रयत्न दुसऱ्या टोकापर्यंत पोहोचल्यास, तोच नियम त्या प्रयत्नाला लागू व्हावा का ते ठरवा. अन्यथा बिनशर्त पुनर्लेखन प्रत्येक पुनर्प्राप्ती मार्गाचे मूळ अपयशात रूपांतर करू शकते.

अपलोड किंवा देयकासारख्या क्रियेत, हरवलेला प्रतिसाद सर्व्हरने विनंती नाकारली हे सिद्ध करत नाही. प्रत्येक वाहतूक अपयश पुनरावृत्तीसाठी सुरक्षित आहे असे सांगण्याऐवजी ती अनिश्चितता पुनःप्रयत्न प्रकरणात समाविष्ट करा.

HTTPS सामग्रीची तपासणी किंवा संपादनासाठी क्लायंटने डीबगिंग प्रॉक्सीच्या TLS तपासणी सेटअपमध्ये सहभागी व्हावे लागते. केवळ CONNECT वाहून नेणारी प्रॉक्सी एन्क्रिप्टेड अनुप्रयोग बाइट्स पाहते. वेगळे चाचणी कॉन्फिगरेशन वापरा आणि नंतर त्याचे राउटिंग व विश्वास सेटअप पुनर्संचयित करा, जेणेकरून पुढील निरीक्षणे सामान्य क्लायंटचे वर्णन करतील.