ડિબગિંગ પ્રોક્સી સાથે નિષ્ફળતાના કેસ ડિઝાઇન કરવા

ડિબગિંગ પ્રોક્સી ત્યારે ઉપયોગી છે જ્યારે ક્લાયન્ટને એવા પ્રતિભાવનો સામનો કરવો પડે જે સામાન્ય સર્વર ભાગ્યે જ બનાવે છે. પહેલા ક્લાયન્ટનું વર્તન વ્યાખ્યાયિત કરો, પછી એ હસ્તક્ષેપ પસંદ કરો જે તે સ્થિતિ ઉત્પન્ન કરે.

“વિનંતી નિષ્ફળ ગઈ” ખૂબ વિશાળ પરીક્ષણ કેસ છે. માન્ય HTTP ભૂલ પ્રતિભાવ, ક્યારેય ન આવતો પ્રતિભાવ અને ડાઉનલોડની વચ્ચે તૂટેલું જોડાણ એપ્લિકેશન પાસેથી જુદી જુદી વસ્તુઓ માંગે છે.

યોગ્ય સ્તર પર હસ્તક્ષેપ વાપરો

Charles એવા બ્રેકપોઇન્ટ આપે છે જે વિનંતી અથવા પ્રતિભાવને આગળ મોકલતા પહેલા થોભાવે છે. અટકાવેલા સંદેશની તપાસ અને સંપાદન કરી શકાય, પસાર થવા દેવાય અથવા રદ કરી શકાય. તેનું Rewrite સાધન મેળ ખાતા હેડર, URL અથવા બોડી પર પુનરાવર્તનીય ફેરફારો લાગુ કરે છે. થ્રોટલિંગ બેન્ડવિડ્થ અને વધારાની લેટન્સી નિયંત્રિત કરે છે.

આ નિયંત્રણો HTTP ક્લાયન્ટનું વર્તન ચકાસી શકે છે, પરંતુ બેન્ડવિડ્થ મર્યાદા રેન્ડમ IP પેકેટ ખોવાઈ જવાનું સચોટ મોડેલ નથી. પ્રોક્સી ડેટા બફર કરી શકે, જોડાણો ફરી વાપરી શકે અને અલગ અપસ્ટ્રીમ જોડાણ ખોલી શકે. જ્યારે જરૂરી સ્થિતિ ખાસ કરીને HTTP નીચે હોય ત્યારે નેટવર્ક ક્ષય સાધન પસંદ કરો.

દરેક કેસને અર્થઘટનયોગ્ય રાખો

ઇચ્છિત યજમાન અને પાથને ચુસ્તપણે મેળવો. સામાન્ય વિનિમયથી શરૂ કરો, એક ફેરફાર સક્ષમ કરો અને શું બદલાયું તે નોંધો. જો ફરી પ્રયાસ બીજા એન્ડપોઇન્ટ સુધી પહોંચે, તો નક્કી કરો કે એ જ નિયમ તે પ્રયાસને અસર કરવો જોઈએ કે નહીં. નહીં તો બિનશરતી પુનર્લેખન દરેક પુનઃપ્રાપ્તિ માર્ગને મૂળ નિષ્ફળતામાં ફેરવી શકે છે.

અપલોડ અથવા ચુકવણી જેવી ક્રિયામાં, ખોવાયેલો પ્રતિભાવ સાબિત કરતો નથી કે સર્વરે વિનંતી નકારી કાઢી. દરેક પરિવહન નિષ્ફળતા પુનરાવર્તન માટે સુરક્ષિત છે એવો દાવો કરવાને બદલે તે અસ્પષ્ટતા ફરી પ્રયાસ કેસમાં સામેલ કરો.

HTTPS સામગ્રીની તપાસ અથવા સંપાદન માટે ક્લાયન્ટે ડિબગિંગ પ્રોક્સીના TLS નિરીક્ષણ સેટઅપમાં ભાગ લેવો પડે. ફક્ત CONNECT વહન કરતી પ્રોક્સી એન્ક્રિપ્ટેડ એપ્લિકેશન બાઇટ્સ જુએ છે. અલગ પરીક્ષણ રૂપરેખાંકન વાપરો અને પછી તેનું રૂટિંગ અને વિશ્વાસ સેટઅપ પુનઃસ્થાપિત કરો જેથી પછીના અવલોકનો સામાન્ય ક્લાયન્ટનું વર્ણન કરે.