Hoe een doorstuurproxy met een aangepaste API-header omgaat

Een API kan zijn versie in een aangepast verzoekveld zoals API-Version dragen. Een gewone doorstuurproxy mag dat veld niet weggooien alleen omdat de naam onbekend is. HTTP schrijft voor dat onbekende velden worden doorgestuurd, tenzij een gedefinieerde uitzondering of een geconfigureerd beleid geldt.

Het veld Connection is zo’n uitzondering. Vergelijk deze voorbeeldverzoeken:

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

Hier is het API-veld niet als lokaal voor deze verbinding aangemerkt. In het volgende voorbeeld wijzigt de afzender de reikwijdte uitdrukkelijk:

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

Een doorstuurproxy verwijdert velden die Connection noemt voordat hij doorstuurt en verwijdert of vervangt de verbindingsspecifieke instructies zelf. Een applicatieheader die voor de oorsprong bedoeld is, hoort daarom niet in die tokenlijst te staan.

Vind het punt waarop het veld verandert

Vergelijk het verzoek dat de client heeft opgebouwd, de velden die de proxy heeft ontvangen en doorgestuurd, en wat de oorsprong heeft ontvangen. Een client kan een header weglaten voordat de proxy hem ziet; een geconfigureerd filter kan hem opzettelijk verwijderen; een server kan een verzoek weigeren omdat een headergrens is overschreden.

Leid geen stilzwijgende verwijdering af uit alleen een drempel voor headergrootte die in een oude uitrol is gemeld. Grenzen en weigeringsgedrag horen bij de werkelijke componenten en configuratie. Bewaar de HTTP-respons en de relevante logboeken bij de waarneming.

Bij end-to-end HTTPS binnen een gewone CONNECT-tunnel kan de proxy het binnenste API-veld niet lezen en selectief verwijderen. Headerinspectie hoort dan bij de TLS-eindpunten of bij een uitdrukkelijk vertrouwde inspectietussenlaag.