Hur en vidarebefordrande proxy hanterar en anpassad API-rubrik

Ett API kan bära sin version i ett anpassat begärandefält som API-Version. En vanlig vidarebefordrande proxy bör inte kasta bort fältet bara för att namnet är okänt. HTTP kräver att okända fält vidarebefordras, om inte ett definierat undantag eller en konfigurerad policy gäller.

Fältet Connection är ett sådant undantag. Jämför dessa illustrativa begäranden:

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

Här är API-fältet inte angivet som lokalt för den här anslutningen. I nästa exempel ändrar avsändaren uttryckligen dess omfattning:

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

En vidarebefordrande proxy tar bort fält som Connection namnger före vidarebefordran och tar bort eller ersätter själva de anslutningsspecifika instruktionerna. En programrubrik avsedd för ursprunget bör därför inte förekomma i den tokenlistan.

Hitta punkten där fältet ändras

Jämför begäran som klienten byggde, fälten som proxyn tog emot och vidarebefordrade, och det ursprunget tog emot. En klient kan utelämna en rubrik innan proxyn ser den; ett konfigurerat filter kan ta bort den med avsikt; en server kan avvisa en begäran eftersom en rubrikgräns överskridits.

Dra inte slutsatsen att borttagning sker tyst bara utifrån en tröskel för rubrikstorlek som rapporterats i en gammal driftsättning. Gränser och avvisningsbeteende hör till de faktiska komponenterna och konfigurationen. Spara HTTP-svaret och relevanta loggar tillsammans med observationen.

Vid HTTPS från ände till ände inuti en vanlig CONNECT-tunnel kan proxyn inte läsa och selektivt ta bort det inre API-fältet. Rubrikinspektion hör då till TLS-ändpunkterna eller till en uttryckligen betrodd inspektionsförmedlare.