ప్రాక్సీ ఫార్వర్డ్ చేసిన అభ్యర్థనను దాని గమ్యస్థానంలో గమనించండి
క్లయింట్ HTTP అభ్యర్థన పంపిన తర్వాత జోడించబడే లేదా మార్చబడే హెడర్లకు సరైన పరిశీలనా బిందువును ఎంచుకోండి.
క్లయింట్ HTTP అభ్యర్థనను సిద్ధం చేస్తుంది, మరియు ఫార్వర్డ్ ప్రాక్సీ ఆ సందేశాన్ని ముందుకు పంపే ముందు మార్చగలదు. ఫార్వర్డ్ చేసిన సంస్కరణను గమనించగలిగే ప్రదేశమే గమ్యస్థానం.
| పరిశీలనా బిందువు | అక్కడ అందుబాటులో ఉన్న సందేశం |
|---|---|
| క్లయింట్ యొక్క అభ్యర్థన వస్తువు | మొదటి దాటకం కోసం సిద్ధం చేసిన అభ్యర్థన |
| మూలం యొక్క అభ్యర్థన లాగ్ లేదా ప్రతిధ్వని నిర్వాహకం | ఫార్వర్డ్ చేసిన తర్వాత స్వీకరించిన అభ్యర్థన |
| క్లయింట్ యొక్క ప్రతిస్పందన-హెడర్ సేకరణ | తిరుగు మార్గంలో స్వీకరించిన ప్రతిస్పందన |
నియంత్రిత పరిశీలన కోసం, మీరే నిర్వహించే మరియు స్వీకరించిన అభ్యర్థన హెడర్లను నమోదు చేసే లేదా తిరిగి ఇచ్చే ముగింపు బిందువును ఉపయోగించండి. అభ్యర్థనకు గుర్తించదగిన గుర్తును ఇవ్వండి, తద్వారా మూల నమోదును నిర్దిష్ట క్లయింట్ చర్యకు అనుసంధానించవచ్చు.
WebClient ఆధారిత అనువర్తనంలో, ResponseHeaders తిరిగి ఇచ్చిన ప్రతిస్పందనను వివరిస్తుంది. ఇది ప్రాక్సీ గమ్యస్థానానికి పంపిన అభ్యర్థన నమోదు కాదు. సర్వర్ తన ప్రతిస్పందన శరీరంలో అభ్యర్థన సమాచారాన్ని ప్రతిధ్వనించేందుకు ఎంచుకోవచ్చు, కానీ అది అనువర్తన ప్రవర్తన.
మార్గంలో అనేక మధ్యవర్తులు ఉంటే, గమ్యస్థానం వారి సంయుక్త ఫార్వర్డింగ్ ప్రభావాలను చూస్తుంది. హెడర్ ఉండటం మాత్రమే మార్పును నిర్దిష్ట దాటకానికి ఆపాదించదు. అనుకూల API క్షేత్రాల కోసం, ఫార్వర్డింగ్ మరియు Connection-క్షేత్రం నియమాలు మార్పు ఎప్పుడు ఆశించబడుతుందో వివరిస్తాయి.
సాధారణ HTTPS CONNECT సొరంగం మరో సరిహద్దును జోడిస్తుంది: లోపలి HTTP అభ్యర్థన క్లయింట్ మరియు వెబ్సైట్ మధ్య గుప్తీకరించబడి ఉంటుంది. రిలే ప్రాక్సీ ఆ గుప్తీకరించిన హెడర్లను సవరించలేదు. CONNECT మార్పిడిలోని హెడర్లు ఆ ప్రత్యేక మార్పిడికి చెందుతాయి, అయితే నిర్వహిత TLS తనిఖీ ప్రాక్సీకి వేరే పాత్ర ఉంటుంది.