Korleis ein videresendande proxy handterer ein eigen API-header

Eit API kan bera versjonen sin i eit eigen forespørselsfelt som API-Version. Ein vanleg videresendande proxy bør ikkje kasta det feltet berre fordi namnet er ukjent. HTTP krev at ukjende felt vert videresende, med mindre eit definert unntak eller ein sett politikk gjeld.

Feltet Connection er eit slikt unntak. Samanlikn desse døme på forespørslar:

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

Her er API-feltet ikkje merkt som lokalt for denne sambindinga. I det neste dømet endrar sendaren omfanget uttrykkeleg:

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

Ein videresendande proxy fjernar felt som Connection nemner før han videresender, og fjernar eller byter ut sjølve dei sambandsspesifikke instruksjonane. Ein applikasjonsheader som er meint for opphavet, bør difor ikkje stå i den tokenlista.

Finn punktet der feltet endrar seg

Samanlikn forespørselen klienten bygde, felta proxyen tok imot og sende vidare, og det opphavet fekk. Ein klient kan utelata ein header før proxyen ser han; eit sett filter kan fjerna han med vilje; ein tenar kan avvisa ein forespørsel fordi ei headergrense er overskriden.

Ikkje slutt at fjerning skjer i det stille berre ut frå ein terskel for headerstorleik som vart rapportert i ei gammal utrulling. Grenser og avvisingåtferd høyrer til dei faktiske komponentane og konfigurasjonen. Ta vare på HTTP-svaret og dei relevante loggane saman med observasjonen.

Ved HTTPS ende-til-ende inne i ein vanleg CONNECT-tunnel kan ikkje proxyen lesa og selektivt fjerna det indre API-feltet. Headerinspeksjon høyrer då til ved TLS-endepunkta eller hos eit uttrykkeleg tiltruleg inspeksjonsmellomledd.