Cómo trata un proxy de reenvío una cabecera API personalizada

Una API puede llevar su versión en un campo de petición personalizado como API-Version. Un proxy de reenvío corriente no debería descartar ese campo solo porque su nombre no le resulte familiar. HTTP exige reenviar los campos no reconocidos salvo que se aplique una excepción definida o una política configurada.

El campo Connection es una de esas excepciones. Compare estas peticiones ilustrativas:

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

Aquí el campo de la API no se ha designado como local de esta conexión. En el siguiente ejemplo, el emisor cambia su alcance de forma explícita:

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

Un proxy de reenvío elimina los campos nombrados por Connection antes de reenviar y elimina o sustituye las propias instrucciones específicas de la conexión. Por tanto, una cabecera de aplicación destinada al origen no debería aparecer en esa lista de tokens.

Encuentre el punto en el que cambia el campo

Compare la petición construida por el cliente, los campos que recibe y reenvía el proxy, y lo que recibió el origen. Un cliente puede omitir una cabecera antes de que el proxy la vea; un filtro configurado puede retirarla a propósito; un servidor puede rechazar una petición por superar un límite de cabeceras.

No deduzca una eliminación silenciosa solo a partir de un umbral de tamaño de cabecera notificado en un despliegue antiguo. Los límites y el comportamiento de rechazo pertenecen a los componentes y a la configuración reales. Conserve la respuesta HTTP y los registros pertinentes junto con la observación.

Con HTTPS de extremo a extremo dentro de un túnel CONNECT corriente, el proxy no puede leer ni retirar de forma selectiva el campo interno de la API. La inspección de cabeceras corresponde entonces a los extremos TLS o a un intermediario de inspección explícitamente de confianza.