Անհաջողության դեպքերի ձևավորում վրիպազերծման պրոքսիով
Ընտրեք HTTP փոփոխությունները, ուշացումները և ընդհատված փոխանակումները՝ ըստ այն հաճախորդի վարքագծի, որը պետք է ստուգի պրոքսիի վրա հիմնված թեստը։
Վրիպազերծման պրոքսին օգտակար է, երբ հաճախորդը պետք է հանդիպի պատասխանի, որը սովորական սերվերը հազվադեպ է արտադրում։ Նախ սահմանեք հաճախորդի վարքագիծը, ապա ընտրեք այն միջամտությունը, որը ստեղծում է այդ վիճակը։
«Հարցումը ձախողվեց» չափազանց լայն փորձարկման դեպք է։ Վավեր HTTP սխալի պատասխանը, պատասխանը, որը երբեք չի հասնում, և ներբեռնման կեսին ընդհատված կապը տարբեր բաներ են պահանջում հավելվածից։
| Դեպք | Ուսումնասիրվող վարքագիծ |
|---|---|
| Ամբողջական HTTP սխալի պատասխան | Արդյոք հաճախորդը կարդում է կարգավիճակը և կիրառում նախատեսված սխալի քաղաքականությունը |
| Ուշացած պատասխան | Արդյոք օգտատերը կարող է չեղարկել, և արդյոք ժամկետը գործում է նախատեսված փուլում |
| Անսպասելի վերնագրի կամ մարմնի դաշտ | Արդյոք վերլուծությունը և վավերացումը հստակ ձախողվում են |
| Ընդհատված փոխանակում | Արդյոք թերի տվյալները մնում են տարբերակելի ավարտված արդյունքից |
Օգտագործեք միջամտություն ճիշտ շերտում
Charles-ը տրամադրում է կանգառի կետեր, որոնք դադարեցնում են հարցումը կամ պատասխանը փոխանցելուց առաջ։ Ընդհատված հաղորդագրությունը կարելի է ուսումնասիրել և խմբագրել, թողնել անցնել կամ չեղարկել։ Նրա Rewrite գործիքը կրկնվող փոփոխություններ է կիրառում համապատասխան վերնագրերի, URL-ների կամ մարմինների վրա։ Սահմանափակումը կառավարում է թողունակությունը և ավելացված ուշացումը։
Այս կառավարիչները կարող են ստուգել HTTP հաճախորդի վարքագիծը, սակայն թողունակության սահմանը պատահական IP փաթեթների կորստի ճշգրիտ մոդել չէ։ Պրոքսին կարող է բուֆերավորել տվյալները, վերօգտագործել կապերը և բացել առանձին վերին հոսքի կապ։ Ընտրեք ցանցի վատթարացման գործիք, երբ պահանջվող պայմանը հատուկ է HTTP-ից ներքև։
Պահեք յուրաքանչյուր դեպք մեկնաբանելի
Նեղորեն համապատասխանեցրեք նախատեսված հոսթին և ուղուն։ Սկսեք սովորական փոխանակումից, միացրեք մեկ փոփոխություն և գրանցեք, թե ինչ փոխվեց։ Եթե կրկնական փորձը հասնում է երկրորդ վերջնակետին, որոշեք՝ արդյոք նույն կանոնը պետք է ազդի այդ փորձի վրա։ Հակառակ դեպքում անվերապահ վերագրումը կարող է յուրաքանչյուր վերականգնման ուղի դարձնել սկզբնական ձախողում։
Վերբեռնման կամ վճարման նման գործողության դեպքում կորած պատասխանը չի ապացուցում, որ սերվերը մերժել է հարցումը։ Ներառեք այդ երկիմաստությունը կրկնական փորձի դեպքում՝ փոխարենը պնդելու, որ յուրաքանչյուր փոխադրման ձախողում անվտանգ է կրկնել։
HTTPS բովանդակության ուսումնասիրությունը կամ խմբագրումը պահանջում է, որ հաճախորդը մասնակցի վրիպազերծման պրոքսիի TLS ուսումնասիրման կարգաբերմանը։ Միայն CONNECT փոխանցող պրոքսին տեսնում է գաղտնագրված հավելվածային բայթեր։ Օգտագործեք առանձնացված թեստային կարգաբերում և դրանից հետո վերականգնեք դրա երթուղավորումը և վստահության կարգավորումները, որպեսզի հետագա դիտարկումները նկարագրեն սովորական հաճախորդին։