Como um proxy de encaminhamento trata um cabeçalho de API personalizado

Uma API pode transportar a sua versão num campo de pedido personalizado como API-Version. Um proxy de encaminhamento comum não deve descartar esse campo só porque o nome não lhe é familiar. O HTTP exige o encaminhamento dos campos não reconhecidos, salvo se se aplicar uma exceção definida ou uma política configurada.

O campo Connection é uma dessas exceções. Compare estes pedidos ilustrativos:

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

Aqui o campo da API não foi designado como local desta ligação. No exemplo seguinte, o emissor altera o âmbito de forma explícita:

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

Um proxy de encaminhamento remove os campos nomeados pelo Connection antes de encaminhar e remove ou substitui as próprias instruções específicas da ligação. Por isso, um cabeçalho de aplicação destinado à origem não deve aparecer nessa lista de tokens.

Encontre o ponto em que o campo muda

Compare o pedido construído pelo cliente, os campos recebidos e encaminhados pelo proxy e o que a origem recebeu. Um cliente pode omitir um cabeçalho antes de o proxy o ver; um filtro configurado pode removê-lo deliberadamente; um servidor pode rejeitar um pedido por exceder um limite de cabeçalhos.

Não deduza uma remoção silenciosa apenas a partir de um limite de tamanho de cabeçalho comunicado numa implementação antiga. Os limites e o comportamento de rejeição pertencem aos componentes e à configuração reais. Guarde a resposta HTTP e os registos relevantes juntamente com a observação.

Em HTTPS de ponta a ponta dentro de um túnel CONNECT comum, o proxy não consegue ler nem remover seletivamente o campo interno da API. A inspeção de cabeçalhos pertence então às extremidades TLS ou a um intermediário de inspeção explicitamente fidedigno.