Hvordan en videresendende proxy håndterer 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 det feltet bare fordi navnet er ukjent. HTTP krever at ukjente felt videresendes, med mindre et definert unntak eller en konfigurert policy gjelder.

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

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

Her er API-feltet ikke angitt som lokalt for denne forbindelsen. I det neste eksempelet endrer avsenderen omfanget eksplisitt:

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 server kan avvise en forespørsel fordi en headergrense er overskredet.

Ikke slutte at fjerning skjer i det stille 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 en eksplisitt betrodd inspeksjonsmellomledd.