Comment un proxy de transfert traite un en-tête API personnalisé

Une API peut porter sa version dans un champ de requête personnalisé tel que API-Version. Un proxy de transfert ordinaire ne devrait pas écarter ce champ simplement parce que son nom ne lui est pas familier. HTTP impose de transférer les champs non reconnus, sauf si une exception définie ou une politique configurée s’applique.

Le champ Connection est l’une de ces exceptions. Comparez ces requêtes d’illustration :

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

Ici, le champ de l’API n’a pas été désigné comme local à cette connexion. Dans l’exemple suivant, l’émetteur modifie explicitement sa portée :

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

Un proxy de transfert supprime les champs nommés par Connection avant de transférer, puis retire ou remplace les instructions propres à la connexion. Un en-tête applicatif destiné à l’origine ne devrait donc pas figurer dans cette liste de jetons.

Repérez le point où le champ change

Comparez la requête construite par le client, les champs reçus et transférés par le proxy, et ce que l’origine a reçu. Un client peut omettre un en-tête avant que le proxy le voie ; un filtre configuré peut le retirer délibérément ; un serveur peut rejeter une requête pour dépassement d’une limite d’en-têtes.

Ne concluez pas à une suppression silencieuse à partir du seul seuil de taille d’en-tête signalé dans un ancien déploiement. Les limites et le comportement de rejet appartiennent aux composants et à la configuration réels. Conservez la réponse HTTP et les journaux pertinents avec l’observation.

Pour du HTTPS de bout en bout dans un tunnel CONNECT ordinaire, le proxy ne peut ni lire ni retirer sélectivement le champ API interne. L’inspection des en-têtes relève alors des extrémités TLS ou d’un intermédiaire d’inspection explicitement digne de confiance.