Resumo

  • Um pedido Upgrade ou CONNECT apresenta uma possibilidade de transição; a resposta é que decide se o outro lado adotou o novo analisador.
  • Se a transição falha, os bytes adiantados podem continuar sujeitos à gramática HTTP/1.1, embora o cliente lhes tenha atribuído outro papel.

Há uma pequena sedução em chamar esse problema de simples atraso de confirmação. Um cliente encerrou a mensagem HTTP/1.1, conhece o protocolo que quer falar em seguida e talvez queira eliminar uma viagem adicional pela rede. Pode então começar a mandar dados desse protocolo antes de receber a resposta. A ação é observável e o ganho de tempo pode parecer real. O que ela não faz é escolher o parser do servidor.

A RFC 9931 fixa esse ponto em regras concretas. Em HTTP/1.1, um Upgrade aceito aparece como 101 Switching Protocols; um CONNECT aceito aparece como resposta bem-sucedida 2xx. A solicitação precisa estar completa antes de o cliente iniciar um protocolo atualizado, mas completar a solicitação não basta. O servidor pode ignorar a oferta, pedir autenticação, redirecionar, recusar o destino ou aplicar uma política local. Antes da resposta, existe uma proposta enviada corretamente, não uma autorização recíproca para mudar a leitura dos bytes seguintes.

O motivo de a distinção merecer atenção de liderança é que a recusa não faz a conexão esquecer os bytes já recebidos. Quando a transição é recusada, o servidor pode continuar interpretando a continuação como HTTP/1.1. Assim, a mesma sequência pode ser vista pelo cliente como o início de um fluxo novo e, pelo receptor, como outra solicitação HTTP. A questão não é se os bytes são "reais". É qual gramática tinha competência para lhes dar significado naquele instante.

Essa competência importa especialmente quando o cliente confiável transporta material escolhido por alguém que não merece a mesma confiança. Um navegador pode carregar dados controlados por outra origem. Um cliente de proxy pode encaminhar payload vindo de uma aplicação local. Se ele antecipa payload para um CONNECT e o proxy recusa o túnel, aquele payload pode encontrar um servidor que ainda o lê em HTTP/1.1. A RFC descreve request smuggling e exploração de divergências de parser como riscos condicionais desse desenho. Ela não atribui um incidente a uma organização nem transforma cada envio antecipado em prova de ataque.

A alteração de connect-udp mostra como uma especificação pode cortar o atalho sem confundir esse corte com uma garantia geral. O envio otimista de datagramas UDP é admitido para HTTP/2 ou posterior; em HTTP/1.x, é vedado por causa do risco de request smuggling. A regra não afirma que uma conexão HTTP/2 está autorizada, que um datagrama chegou ao destino ou que um serviço posterior teve sucesso. Ela limita onde uma previsão do cliente pode se tornar uma ambiguidade de interpretação para outra parte.

O tratamento de CONNECT para tráfego TCP de terceiros é igualmente específico. O cliente de proxy deve esperar a resposta 2xx antes de encaminhar payload ou usar Connection: close. Depois de rejeitar CONNECT, o servidor proxy deve fechar a conexão subjacente antes de processar outra solicitação. Esses controles preservam uma cadeia legível: origem do payload, pedido de transição, decisão do proxy, parser efetivo e ação posterior. Não são um selo de identidade, autorização ou valor de negócio.

O registro que resiste a auditoria mantém os verbos separados: o cliente propôs; a solicitação terminou; a resposta foi observada; a transição foi aceita ou recusada; o payload foi retido ou encaminhado; a conexão foi fechada; um efeito posterior foi observado. A ênfase de Heng Lu em código em execução não encurta essa cadeia. Uma captura ou log pode provar um fato no seu nível, mas não pode tomar para si a decisão de política, a aceitação do par ou o efeito que outra camada ainda precisa demonstrar.

Fontes