ફોરવર્ડ પ્રોક્સી કસ્ટમ API હેડરને કેવી રીતે સંભાળે છે

એક API પોતાનું સંસ્કરણ API-Version જેવા કસ્ટમ વિનંતી ક્ષેત્રમાં રાખી શકે છે. સામાન્ય ફોરવર્ડિંગ પ્રોક્સીએ ફક્ત નામ અજાણ્યું હોવાના કારણે તે ક્ષેત્રને કાઢી નાખવું જોઈએ નહીં. HTTP અજાણ્યા ક્ષેત્રોને ફોરવર્ડ કરવાનું ફરજિયાત બનાવે છે, સિવાય કે વ્યાખ્યાયિત અપવાદ અથવા ગોઠવાયેલ નીતિ લાગુ પડે.

Connection ક્ષેત્ર આવા અપવાદોમાંનું એક છે. આ ઉદાહરણ વિનંતીઓની સરખામણી કરો:

API-Version: 2026-10
Connection: keep-alive

અહીં API ક્ષેત્રને આ જોડાણ માટે સ્થાનિક તરીકે નિર્દિષ્ટ કરવામાં આવ્યું નથી. આગલા ઉદાહરણમાં મોકલનાર તેનો વ્યાપ સ્પષ્ટ રૂપે બદલે છે:

API-Version: 2026-10
Connection: API-Version

ફોરવર્ડિંગ પ્રોક્સી ફોરવર્ડ કરતાં પહેલાં Connection દ્વારા નામ આપેલા ક્ષેત્રો દૂર કરે છે અને જોડાણ-વિશિષ્ટ સૂચનાઓ પોતે દૂર કરે છે અથવા બદલે છે. તેથી મૂળ સ્રોત માટે ઇચ્છિત એપ્લિકેશન હેડર તે ટોકન યાદીમાં ન હોવું જોઈએ.

ક્ષેત્ર જ્યાં બદલાય છે તે બિંદુ શોધો

ક્લાયન્ટે બનાવેલી વિનંતી, પ્રોક્સીએ મેળવેલા અને ફોરવર્ડ કરેલા ક્ષેત્રો, અને મૂળ સ્રોતને શું મળ્યું તેની સરખામણી કરો. ક્લાયન્ટ પ્રોક્સી તેને જોવા પહેલાં હેડર છોડી શકે છે; ગોઠવાયેલ ફિલ્ટર જાણી જોઈને તેને દૂર કરી શકે છે; સર્વર હેડર મર્યાદા વટાવવાના કારણે વિનંતી નકારી શકે છે.

જૂની ડિપ્લોયમેન્ટમાં જણાવાયેલ હેડર-કદની મર્યાદા પરથી જ મૌન દૂર કરવાનું અનુમાન ન કરો. મર્યાદાઓ અને નકારવાનું વર્તન વાસ્તવિક ઘટકો અને ગોઠવણીને આધીન છે. HTTP પ્રતિસાદ અને સંબંધિત લોગ અવલોકન સાથે રાખો.

સામાન્ય CONNECT ટનલની અંદર એન્ડ-ટુ-એન્ડ HTTPS માટે પ્રોક્સી અંદરનું API ક્ષેત્ર વાંચી શકતું નથી કે પસંદગીથી દૂર કરી શકતું નથી. ત્યારે હેડર નિરીક્ષણ TLS છેડા પર અથવા સ્પષ્ટ રૂપે વિશ્વસનીય નિરીક્ષણ મધ્યસ્થ પાસે રહે છે.