Resumo

  • A RFC 9110 define Via como registro ordenado dos proxies e gateways HTTP que encaminharam uma mensagem específica; entradas podem usar pseudônimos e, sob condições limitadas, ser combinadas.
  • Uma afirmação de caminho completo precisa ligar os campos exatos da requisição e resposta a registros de entrada e saída, configuração, túneis, camadas inferiores, transformações e tempos.

Imagine uma análise de incidente em que a requisição chega com dois membros Via. O painel transforma as duas entradas em um diagrama e declara que apenas dois intermediários participaram do encaminhamento. Um portal de firewall, porém, ocultou nomes internos com um pseudônimo; dois gateways do mesmo operador combinaram entradas do mesmo protocolo; um túnel transportou bytes sem continuar como participante HTTP; e um redirecionamento em camada inferior jamais apareceu no campo.

O caso é hipotético e não relata um provedor. Ele mostra um erro de evidência: interpretar um campo de protocolo além do escopo dos participantes e das regras de divulgação que o produziram.

A RFC 9110 distingue proxy, gateway e túnel. O proxy é escolhido pelo cliente e encaminha mensagens. O gateway se apresenta externamente como servidor de origem e traduz ou encaminha o tráfego para dentro. O túnel vira um retransmissor cego entre conexões e, depois de ativo, deixa de ser parte da comunicação HTTP. Equipamentos de camada inferior também podem filtrar ou redirecionar tráfego sem que os emissores HTTP saibam. A influência deles não cria uma entrada Via.

O campo tem uma função delimitada. Em uma requisição, indica protocolos e destinatários intermediários entre agente do usuário e servidor; em uma resposta, entre servidor de origem e cliente. Cada membro representa um proxy ou gateway que encaminhou aquela mensagem. received-protocol registra a versão de protocolo usada pelo emissor anterior, enquanto received-by identifica o destinatário, sujeito a pseudonimização. A ordem ajuda a evitar loops, rastrear encaminhamentos e preservar capacidades de protocolo anunciadas a jusante.

As obrigações são assimétricas, e um mesmo intermediário pode mudar de função entre requisições. Quando atua como proxy, deve adicionar um Via apropriado a toda mensagem encaminhada. Quando atua como gateway HTTP para HTTP, e não como túnel ativo, deve adicioná-lo às requisições de entrada, enquanto sua inclusão nas respostas encaminhadas é opcional. Ao passar a operar como túnel ativo, deixa de ser participante da comunicação HTTP. A lista da resposta não precisa espelhar a lista da requisição. Comparar contagens sem direção, identidade da mensagem, função exercida e ponto de captura inventa uma simetria que a norma não promete.

received-by também não é cadastro estável. Em geral contém host e porta opcional, mas o host real pode ser trocado por pseudônimo quando for sensível. Um portal de firewall deve ocultar nomes internos salvo autorização explícita. Comentários sobre software são opcionais e podem ser removidos. Como Via não é autenticado, um token é uma declaração de encaminhamento; a participação precisa ser corroborada por captura confiável e prova de integridade. Sozinho, ele não identifica endereço roteável, máquina, processo ou entidade operadora.

Até o tamanho da lista precisa de contexto. A RFC 9110 só permite combinar uma subsequência ordenada quando seus membros compartilham o mesmo received-protocol; mesmo assim, o emissor não deveria fazê-lo se eles não estiverem também sob o mesmo controle organizacional ou se os hosts ainda não tiverem sido substituídos por pseudônimos. Protocolos recebidos diferentes não podem ser combinados. Consideradas em conjunto, essas condições preservam a fronteira de capacidade e só permitem comprimir uma topologia interna controlada e pseudonimizada. Um membro visível pode resumir vários intermediários.

Transformações pertencem a outro plano de prova. Um proxy pode alterar campos ou conteúdo. Um gateway pode traduzir entre HTTP e protocolo privado. Um túnel pode carregar bytes cifrados sem expor as mensagens ou retransmissores internos. Via registra participação no encaminhamento HTTP, mas não atribui integralmente mudanças, cache, inspeção de segurança, balanceamento nem enlaces físicos.

Um recibo de custódia da mensagem deve preservar identidade exata de requisição e resposta, valores Via brutos em cada captura, protocolo e direção, mapa de pseudônimos, regra de combinação, horários de entrada e saída, cache, transformação, extremos do túnel e observações das camadas inferiores. “Não visível em Via” deve permanecer diferente de “ausente do caminho”. O recibo é uma síntese operacional editorial, não objeto de protocolo da IETF.

A fronteira separa este trabalho dos temas próximos. Endereços IPv6 temporários tratam de correlação após rotação. BFD trata de vivacidade limitada e escolha de rota. HTTP Priority trata do efeito de uma preferência de escalonamento. Via trata da procedência e completude de um registro de encaminhamento.

Fontes