Wie ein Forward-Proxy einen benutzerdefinierten API-Header behandelt

Eine API kann ihre Version in einem benutzerdefinierten Anforderungsfeld wie API-Version tragen. Ein gewöhnlicher Forward-Proxy sollte dieses Feld nicht allein deshalb verwerfen, weil der Name unbekannt ist. HTTP verlangt, unbekannte Felder weiterzuleiten, sofern keine definierte Ausnahme oder konfigurierte Richtlinie greift.

Das Feld Connection ist eine solche Ausnahme. Vergleichen Sie diese beispielhaften Anforderungen:

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

Hier wurde das API-Feld nicht als lokal für diese Verbindung gekennzeichnet. Im nächsten Beispiel ändert der Absender seinen Geltungsbereich ausdrücklich:

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

Ein Forward-Proxy entfernt die von Connection benannten Felder vor dem Weiterleiten und entfernt oder ersetzt die verbindungsspezifischen Anweisungen selbst. Ein für den Ursprung bestimmter Anwendungs-Header sollte daher nicht in dieser Token-Liste erscheinen.

Finden Sie die Stelle, an der sich das Feld ändert

Vergleichen Sie die vom Client aufgebaute Anforderung, die vom Proxy empfangenen und weitergeleiteten Felder und das, was der Ursprung erhielt. Ein Client kann einen Header weglassen, bevor der Proxy ihn sieht; ein konfigurierter Filter kann ihn gezielt entfernen; ein Server kann eine Anforderung ablehnen, weil ein Header-Limit überschritten wurde.

Schließen Sie nicht allein aus einer in einem alten Deployment gemeldeten Header-Größenschwelle auf stilles Entfernen. Grenzwerte und Ablehnungsverhalten gehören zu den tatsächlichen Komponenten und der Konfiguration. Bewahren Sie die HTTP-Antwort und die relevanten Protokolle zusammen mit der Beobachtung auf.

Bei durchgehendem HTTPS innerhalb eines gewöhnlichen CONNECT-Tunnels kann der Proxy das innere API-Feld nicht lesen und gezielt entfernen. Die Header-Prüfung gehört dann an die TLS-Endpunkte oder zu einem ausdrücklich vertrauenswürdigen Prüfvermittler.