Hvordan en videresendende proxy behandler en egendefinert API-header

Et API kan bære versjonen sin i et egendefinert forespørselsfelt som API-Version. En vanlig videresendende proxy bør ikke forkaste feltet bare fordi navnet er ukjent. HTTP krever at ukjente felt sendes videre, med mindre et definert unntak eller en konfigurert policy gjelder.

Connection-feltet er ett slikt unntak. Sammenlign disse eksempelforespørslene:

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

Her er ikke API-feltet angitt som lokalt for denne forbindelsen. I neste eksempel endrer avsenderen omfanget sitt uttrykkelig:

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

En videresendende proxy fjerner felt som Connection navngir før videresending og fjerner eller erstatter selve de forbindelsesspesifikke instruksjonene. En applikasjonsheader som er ment for opprinnelsen, bør derfor ikke forekomme i den tokenlisten.

Finn punktet der feltet endres

Sammenlign forespørselen klienten bygde, feltene proxyen mottok og videresendte, og det opprinnelsen mottok. En klient kan utelate en header før proxyen ser den; et konfigurert filter kan fjerne den med vilje; en tjener kan avvise en forespørsel fordi en headergrense er overskredet.

Ikke slut at fjerning skjer i stillhet bare ut fra en terskel for headerstørrelse rapportert i en gammel utrulling. Grenser og avvisningsatferd hører til de faktiske komponentene og konfigurasjonen. Ta vare på HTTP-svaret og de relevante loggene sammen med observasjonen.

Ved HTTPS ende-til-ende inne i en vanlig CONNECT-tunnel kan ikke proxyen lese og selektivt fjerne det indre API-feltet. Headerinspeksjon hører da til ved TLS-endepunktene eller hos et uttrykkelig betrodd inspeksjonsmellomledd.