പ്രോക്സി കൈമാറിയ അഭ്യർത്ഥന അതിന്റെ ലക്ഷ്യസ്ഥാനത്ത് നിരീക്ഷിക്കുക
ക്ലയന്റ് HTTP അഭ്യർത്ഥന അയച്ചതിന് ശേഷം ചേർക്കുന്നതോ മാറ്റുന്നതോ ആയ ഹെഡറുകൾക്ക് ശരിയായ നിരീക്ഷണ കേന്ദ്രം തിരഞ്ഞെടുക്കുക.
ഒരു ക്ലയന്റ് HTTP അഭ്യർത്ഥന തയ്യാറാക്കുന്നു, ഒരു ഫോർവേഡ് പ്രോക്സിക്ക് അത് മുന്നോട്ട് അയക്കുന്നതിന് മുമ്പ് ആ സന്ദേശം മാറ്റാനാകും. കൈമാറിയ പതിപ്പ് നിരീക്ഷിക്കാനാകുന്ന സ്ഥലമാണ് ലക്ഷ്യസ്ഥാനം.
| നിരീക്ഷണ കേന്ദ്രം | അവിടെ ലഭ്യമായ സന്ദേശം |
|---|---|
| ക്ലയന്റിന്റെ അഭ്യർത്ഥന ഒബ്ജക്റ്റ് | ആദ്യ ചുവടിനായി തയ്യാറാക്കിയ അഭ്യർത്ഥന |
| ഉറവിടത്തിന്റെ അഭ്യർത്ഥന ലോഗ് അല്ലെങ്കിൽ മാറ്റൊലി കൈകാര്യം ചെയ്യുന്നത് | കൈമാറിയതിന് ശേഷം ലഭിച്ച അഭ്യർത്ഥന |
| ക്ലയന്റിന്റെ പ്രതികരണ ഹെഡർ ശേഖരം | തിരിച്ചുവരവ് പാതയിൽ ലഭിച്ച പ്രതികരണം |
നിയന്ത്രിത പരിശോധനയ്ക്ക്, നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതും ലഭിച്ച അഭ്യർത്ഥന ഹെഡറുകൾ രേഖപ്പെടുത്തുന്നതോ തിരികെ നൽകുന്നതോ ആയ ഒരു എൻഡ്പോയിന്റ് ഉപയോഗിക്കുക. അഭ്യർത്ഥനയ്ക്ക് തിരിച്ചറിയാവുന്ന ഒരു അടയാളം നൽകുക, അതുവഴി ഉറവിട രേഖയെ പ്രത്യേക ക്ലയന്റ് പ്രവർത്തനവുമായി ബന്ധിപ്പിക്കാം.
WebClient അടിസ്ഥാനമാക്കിയ ആപ്ലിക്കേഷനിൽ, ResponseHeaders തിരികെ നൽകിയ പ്രതികരണത്തെ വിവരിക്കുന്നു. ഇത് പ്രോക്സിയുടെ ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള അഭ്യർത്ഥനയുടെ രേഖയല്ല. സെർവർക്ക് അതിന്റെ പ്രതികരണ ബോഡിയിൽ അഭ്യർത്ഥന വിവരങ്ങൾ മാറ്റൊലിപ്പിക്കാൻ തിരഞ്ഞെടുക്കാം, പക്ഷേ അത് ആപ്ലിക്കേഷൻ സ്വഭാവമാണ്.
പാതയിൽ നിരവധി ഇടനിലക്കാർ ഉണ്ടെങ്കിൽ, ലക്ഷ്യസ്ഥാനം അവരുടെ സംയുക്ത ഫോർവേഡിംഗ് ഫലങ്ങൾ കാണുന്നു. ഒരു ഹെഡർ ഉണ്ടെന്നത് മാത്രം ഒരു മാറ്റത്തെ ഒരു പ്രത്യേക ചുവടിന് ആരോപിക്കുന്നില്ല. ഇഷ്ടാനുസൃത API ഫീൽഡുകൾക്ക്, ഫോർവേഡിംഗ്, Connection ഫീൽഡ് നിയമങ്ങൾ എപ്പോൾ മാറ്റം പ്രതീക്ഷിക്കാമെന്ന് വിശദീകരിക്കുന്നു.
സാധാരണ HTTPS CONNECT തുരങ്കം മറ്റൊരു അതിർത്തി കൂട്ടിച്ചേർക്കുന്നു: ഉള്ളിലെ HTTP അഭ്യർത്ഥന ക്ലയന്റിനും വെബ്സൈറ്റിനും ഇടയിൽ എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു. ഒരു റിലേ പ്രോക്സിക്ക് ആ എൻക്രിപ്റ്റ് ചെയ്ത ഹെഡറുകൾ തിരുത്താനാവില്ല. CONNECT കൈമാറ്റത്തിലെ ഹെഡറുകൾ ആ വേറിട്ട കൈമാറ്റത്തിനുള്ളതാണ്, അതേസമയം നിയന്ത്രിത TLS പരിശോധനാ പ്രോക്സിക്ക് വ്യത്യസ്ത പങ്കുണ്ട്.