Como trata un proxy de reenvío unha cabeceira API personalizada

Unha API pode levar a súa versión nun campo de petición personalizado como API-Version. Un proxy de reenvío común non debería descartar ese campo só porque o nome non lle resulta familiar. HTTP esixe reenviar os campos non recoñecidos salvo que se aplique unha excepción definida ou unha política configurada.

O campo Connection é unha desas excepcións. Compare estas peticións ilustrativas:

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

Aquí o campo da API non se designou como local desta conexión. No exemplo seguinte, o emisor cambia o seu alcance de forma explícita:

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

Un proxy de reenvío elimina os campos nomeados por Connection antes de reenviar e elimina ou substitúe as propias instrucións específicas da conexión. Por tanto, unha cabeceira de aplicación destinada á orixe non debería aparecer nesa lista de tokens.

Atope o punto no que cambia o campo

Compare a petición construída polo cliente, os campos que recibe e reenvía o proxy, e o que recibiu a orixe. Un cliente pode omitir unha cabeceira antes de que o proxy a vexa; un filtro configurado pode retirala a propósito; un servidor pode rexeitar unha petición por superar un límite de cabeceiras.

Non deduza unha eliminación silenciosa só a partir dun limiar de tamaño de cabeceira notificado nun despregamento antigo. Os límites e o comportamento de rexeitamento pertencen aos compoñentes e á configuración reais. Conserve a resposta HTTP e os rexistros pertinentes xunto coa observación.

Con HTTPS de extremo a extremo dentro dun túnel CONNECT común, o proxy non pode ler nin retirar de forma selectiva o campo interno da API. A inspección de cabeceiras corresponde entón aos extremos TLS ou a un intermediario de inspección explicitamente de confianza.