Cum tratează un proxy de redirecționare un antet API personalizat

Urmăriți un câmp de versiune API prin redirecționarea normală, regulile Connection specifice fiecărui salt și o politică de antete configurată explicit.

Un API își poate purta versiunea într-un câmp de cerere personalizat, cum ar fi API-Version. Un proxy de redirecționare obișnuit nu ar trebui să elimine acel câmp doar pentru că numele nu îi este familiar. HTTP impune redirecționarea câmpurilor nerecunoscute, cu excepția cazului în care se aplică o excepție definită sau o politică configurată.

Câmpul Connection este una dintre aceste excepții. Comparați aceste cereri ilustrative:

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

Aici câmpul API nu a fost desemnat ca local pentru această conexiune. În exemplul următor, expeditorul îi schimbă explicit domeniul:

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

Un proxy de redirecționare elimină câmpurile numite de Connection înainte de redirecționare și elimină sau înlocuiește instrucțiunile specifice conexiunii. Prin urmare, un antet de aplicație destinat originii nu ar trebui să apară în acea listă de tokenuri.

Găsiți punctul în care se schimbă câmpul

Comparați cererea construită de client, câmpurile primite și redirecționate de proxy și ce a primit originea. Un client poate omite un antet înainte ca proxy-ul să îl vadă; un filtru configurat îl poate elimina intenționat; un server poate respinge o cerere pentru depășirea unei limite de antete.

Nu deduceți o eliminare silențioasă doar dintr-un prag de dimensiune a antetului raportat într-o implementare veche. Limitele și comportamentul de respingere aparțin componentelor și configurației reale. Păstrați răspunsul HTTP și jurnalele relevante împreună cu observația.

Pentru HTTPS de la un capăt la altul într-un tunel CONNECT obișnuit, proxy-ul nu poate citi și elimina selectiv câmpul API interior. Inspecția antetelor aparține atunci extremităților TLS sau unui intermediar de inspecție în care se are încredere explicită.

Articole similare