પ્રોક્સીની ફોરવર્ડ કરેલી વિનંતીને તેના ગંતવ્ય પર અવલોકન કરો
ક્લાયન્ટ HTTP વિનંતી મોકલ્યા પછી ઉમેરાયેલા કે બદલાયેલા હેડરો માટે યોગ્ય અવલોકન બિંદુ પસંદ કરો.
ક્લાયન્ટ HTTP વિનંતી તૈયાર કરે છે, અને ફોરવર્ડ પ્રોક્સી તે સંદેશને આગળ મોકલતાં પહેલાં બદલી શકે છે. ફોરવર્ડ કરેલી આવૃત્તિ જ્યાં અવલોકનયોગ્ય બને છે તે ગંતવ્ય છે.
| અવલોકન બિંદુ | ત્યાં ઉપલબ્ધ સંદેશ |
|---|---|
| ક્લાયન્ટનું વિનંતી ઑબ્જેક્ટ | પ્રથમ કૂદકા માટે તૈયાર કરેલી વિનંતી |
| મૂળનું વિનંતી લોગ અથવા ઇકો હેન્ડલર | ફોરવર્ડ કર્યા પછી મળેલી વિનંતી |
| ક્લાયન્ટનો પ્રતિસાદ-હેડર સંગ્રહ | પરત માર્ગ પર મળેલો પ્રતિસાદ |
નિયંત્રિત ચકાસણી માટે, તમે ચલાવો છો તેવું એન્ડપોઇન્ટ વાપરો જે મળેલા વિનંતી હેડરો નોંધે અથવા પરત આપે. વિનંતીને ઓળખી શકાય તેવું ચિહ્ન આપો જેથી મૂળનો રેકોર્ડ ચોક્કસ ક્લાયન્ટ ક્રિયા સાથે જોડી શકાય.
WebClient આધારિત એપ્લિકેશનમાં, ResponseHeaders પરત આપેલા પ્રતિસાદનું વર્ણન કરે છે. તે પ્રોક્સીની ગંતવ્ય તરફની વિનંતીનો રેકોર્ડ નથી. સર્વર તેના પ્રતિસાદના ભાગમાં વિનંતીની માહિતી પુનઃગૂંજી શકે છે, પરંતુ તે એપ્લિકેશનનું વર્તન છે.
જો માર્ગમાં ઘણા મધ્યસ્થો હોય, તો ગંતવ્ય તેમના સંયુક્ત ફોરવર્ડિંગ પ્રભાવો જુએ છે. ફક્ત હેડરની હાજરી પરિવર્તનને કોઈ ચોક્કસ કૂદકાને આભારી ગણાવતી નથી. કસ્ટમ API ક્ષેત્રો માટે, ફોરવર્ડિંગ અને Connection-ક્ષેત્રના નિયમો સમજાવે છે કે પરિવર્તન ક્યારે અપેક્ષિત છે.
સામાન્ય HTTPS CONNECT સુરંગ બીજી સીમા ઉમેરે છે: આંતરિક HTTP વિનંતી ક્લાયન્ટ અને વેબસાઇટ વચ્ચે એન્ક્રિપ્ટ થયેલી હોય છે. રિલે પ્રોક્સી તે એન્ક્રિપ્ટ થયેલા હેડરોમાં ફેરફાર કરી શકતું નથી. CONNECT આદાન-પ્રદાનના હેડરો તે અલગ આદાન-પ્રદાનના છે, જ્યારે સંચાલિત TLS નિરીક્ષણ પ્રોક્સીની ભૂમિકા અલગ છે.