Sådan håndterer en videresendende proxy en brugerdefineret API-header
Følg et API-versionsfelt gennem normal videresendelse, hop-specifikke Connection-regler og en eksplicit konfigureret headerpolitik.
En API kan bære sin version i et brugerdefineret anmodningsfelt som API-Version. En almindelig videresendende proxy bør ikke kassere det felt, blot fordi navnet er ukendt. HTTP kræver, at ukendte felter videresendes, medmindre en defineret undtagelse eller en konfigureret politik gælder.
Connection-feltet er en sådan undtagelse. Sammenlign disse illustrerende anmodninger:
API-Version: 2026-10
Connection: keep-alive
Her er API-feltet ikke udpeget som lokalt for denne forbindelse. I det næste eksempel ændrer afsenderen udtrykkeligt dets omfang:
API-Version: 2026-10
Connection: API-Version
En videresendende proxy fjerner felter, som Connection navngiver, før videresendelsen og fjerner eller erstatter selve de forbindelsesspecifikke instrukser. En applikationsheader, der er beregnet til oprindelsen, bør derfor ikke optræde på den tokenliste.
Find det punkt, hvor feltet ændres
Sammenlign den anmodning, klienten har bygget, de felter, proxyen har modtaget og videresendt, og hvad oprindelsen modtog. En klient kan udelade en header, før proxyen ser den; et konfigureret filter kan bevidst fjerne den; en server kan afvise en anmodning, fordi en headergrænse er overskredet.
Slut ikke til tavs fjernelse alene ud fra en tærskel for headerstørrelse rapporteret i en gammel udrulning. Grænser og afvisningsadfærd hører til de faktiske komponenter og den faktiske konfiguration. Gem HTTP-svaret og de relevante logfiler sammen med observationen.
Ved HTTPS fra ende til ende inde i en almindelig CONNECT-tunnel kan proxyen ikke læse og selektivt fjerne det indre API-felt. Headerinspektion hører da til ved TLS-endepunkterne eller hos en udtrykkeligt betroet inspektionsmellemled.