प्रॉक्सीने पुढे पाठवलेली विनंती तिच्या गंतव्यस्थानी पाहा
क्लायंटने HTTP विनंती पाठवल्यानंतर जोडल्या किंवा बदलल्या जाणाऱ्या हेडरसाठी योग्य निरीक्षण बिंदू निवडा.
क्लायंट HTTP विनंती तयार करतो, आणि फॉरवर्ड प्रॉक्सी तो संदेश पुढे पाठवण्यापूर्वी बदलू शकतो. पुढे पाठवलेली आवृत्ती निरीक्षणयोग्य होते ते ठिकाण म्हणजे गंतव्यस्थान.
| निरीक्षण बिंदू | तिथे उपलब्ध संदेश |
|---|---|
| क्लायंटचा विनंती ऑब्जेक्ट | पहिल्या झेपेसाठी तयार केलेली विनंती |
| मूळचा विनंती लॉग किंवा प्रतिध्वनी हाताळणारा | पुढे पाठवल्यानंतर मिळालेली विनंती |
| क्लायंटचा प्रतिसाद-हेडर संग्रह | परतीच्या मार्गावर मिळालेला प्रतिसाद |
नियंत्रित तपासणीसाठी, तुम्ही चालवता तो आणि मिळालेले विनंती हेडर नोंदवणारा किंवा परत देणारा एंडपॉइंट वापरा. विनंतीला ओळखता येण्याजोगी खूण द्या, जेणेकरून मूळची नोंद विशिष्ट क्लायंट क्रियेशी जोडता येईल.
WebClient-आधारित अनुप्रयोगात, ResponseHeaders परत दिलेल्या प्रतिसादाचे वर्णन करते. ही प्रॉक्सीच्या गंतव्यस्थानाकडे पाठवलेल्या विनंतीची नोंद नाही. सर्व्हर त्याच्या प्रतिसादाच्या मुख्य भागात विनंतीची माहिती पुन्हा देऊ शकतो, परंतु ते अनुप्रयोगाचे वर्तन आहे.
जर मार्गात अनेक मध्यस्थ असतील, तर गंतव्यस्थान त्यांचे एकत्रित फॉरवर्डिंग परिणाम पाहते. केवळ हेडर असणे बदलाला एका विशिष्ट झेपेला जोडत नाही. सानुकूल API फील्डसाठी, फॉरवर्डिंग आणि Connection-फील्डचे नियम बदल केव्हा अपेक्षित आहे ते स्पष्ट करतात.
सामान्य HTTPS CONNECT बोगदा आणखी एक सीमा जोडतो: आतील HTTP विनंती क्लायंट आणि वेबसाइट दरम्यान एन्क्रिप्ट केलेली असते. रिले प्रॉक्सी ते एन्क्रिप्ट केलेले हेडर संपादित करू शकत नाही. CONNECT देवघेवीतील हेडर त्या वेगळ्या देवघेवीचे आहेत, तर व्यवस्थापित TLS तपासणी प्रॉक्सीची भूमिका वेगळी आहे.