Resumo

  • Pela RFC 9110, um cliente pode enviar Upgrade para convidar uma mudança de protocolo na mesma conexão; o servidor pode ignorá-lo e um intermediário deve remover esse campo específico da conexão antes do encaminhamento comum.
  • A prova de uma transição concluída começa com uma resposta válida 101 Switching Protocols que escolhe um protocolo oferecido e inclui o fim da requisição original e a primeira troca válida no novo protocolo.

Imagine um painel de migração que encontra Upgrade: websocket em uma requisição e marca imediatamente a sessão como “WebSocket ativo”. Entre cliente e origem, porém, um proxy aplica o campo Connection e remove o convite limitado àquele enlace. A origem nunca o recebe e responde com um 200 OK normal em HTTP/1.1. Nenhuma ponta muda de protocolo, mas o painel registra sucesso porque tratou uma oferta como resultado.

É um cenário hipotético, não um relato sobre um provedor específico. O erro é probatório: uma observação feita de um lado não demonstra uma transição que depende de fatos ordenados nos dois lados de uma fronteira.

A RFC 9110 define Upgrade como mecanismo para passar de HTTP/1.1 a outro protocolo sobre a mesma conexão. O cliente pode enviar uma lista ordenada de protocolos para convidar o servidor a mudar conforme suas preferências. O servidor pode ignorar o convite. Portanto, o campo expressa disposição e preferência, não aceitação, êxito da negociação ou disponibilidade real.

O convite é específico da conexão. Quem envia Upgrade deve incluir upgrade em Connection. A regra impede que intermediários encaminhem sem critério a opção recebida como se fosse ponta a ponta. Antes de reenviar a mensagem, o intermediário remove os campos indicados por Connection. Se um proxy aceita o protocolo solicitado e decide convidar o próximo salto, pode gerar um novo Upgrade específico daquele enlace e deve incluir upgrade em seu próprio campo Connection. Uma captura na borda do cliente não comprova, portanto, que a origem recebeu a mesma oferta; uma captura na origem tampouco comprova que o cliente recebeu a resposta sem alteração. Um servidor HTTP/1.0 que receba Upgrade deve ignorá-lo.

A aceitação válida tem forma mais exigente. O servidor que muda de protocolo deve enviar 101 Switching Protocols e um campo Upgrade que identifique o protocolo selecionado. Ele não pode escolher um protocolo que o cliente não ofereceu. O 101 é a fronteira de decisão: antes dele há proposta; depois de uma resposta válida, as partes concordam em reinterpretar a mesma conexão.

Mesmo a linha 101 não completa o recibo. O cliente não pode iniciar o protocolo novo antes de terminar de enviar a requisição que continha o convite. O servidor não pode mudar se o novo protocolo não preservar a semântica da mensagem recebida. Depois da mudança, espera-se que o servidor continue respondendo à requisição original de modo equivalente a uma resposta HTTP dentro do protocolo escolhido. A prova precisa do limite de conclusão da requisição e da primeira troca bem formada.

O mecanismo não troca o transporte inferior nem cria outra conexão. Muda somente o protocolo de aplicação superior da conexão existente. Ligar uma oferta de uma conexão a um 101 ou quadro de outra fabrica uma transição que a norma não descreve. Identidade da conexão, ordem dos bytes e direção da captura são indispensáveis.

Esta lente é distinta de R067 sobre a cobertura de Via, R064 sobre Alt-Svc e caminho alternativo, Strategic Local sobre restauração de prioridade e B842 sobre correlação de identificadores IPv6 temporários. Aqui, o evento controlado é uma troca de protocolo de aplicação presa a uma conexão, e sua prova é um recibo ordenado de negociação e troca.

Um registro confiável reúne requisição exata, ofertas ordenadas, tokens Connection, observações antes e depois de cada intermediário, estado final, protocolo selecionado, fim dos bytes da requisição, ponto da troca, primeira mensagem válida no protocolo novo e eventual fallback ou fechamento. Esse registro não é um elemento de protocolo definido pela IETF, mas uma síntese editorial de evidências operacionais. “Oferta observada” deve continuar diferente de “troca concluída”.

Fontes