Resumo

  • draft-ietf-httpbis-connect-tcp-14 identifica o serviço por um URI Template com target_host e target_port; a expansão cria o recurso da conexão connect-tcp.
  • O modelo escolhe origem, caminho, protection space e ponto de aplicação da política. Por isso, sua proveniência faz parte da autorização.
  • A Last Call termina em 1º de outubro de 2026. O documento continua sendo Internet-Draft, sem provar aprovação, implementação ou operação em produção.

A configuração passou a escolher o porteiro

No CONNECT clássico, host e porta do destino aparecem diretamente. Na revisão 14, o cliente recebe um modelo de URI, insere os valores de target_host e target_port e envia a solicitação ao recurso resultante no proxy.

Essa URI define onde as credenciais chegam, qual rota o gateway seleciona e a qual origem se ligam HSTS, Alt-Svc, cookies e outros estados. Quem controla o modelo não controla apenas uma forma textual; controla a porta de entrada.

O projeto incorpora as exigências do RFC 9298. O modelo precisa ser absoluto, ter scheme, authority e path não vazios, manter variáveis em path ou query, conter host e porta e evitar certos operadores de expansão. Se detectar violação, o cliente deve rejeitar a configuração antes de enviar a requisição.

Isso demonstra conformidade sintática. Não demonstra quem publicou o modelo, se esse ator pode alterar a saída nem se a origem pertence ao serviço administrativo pretendido. Uma configuração adulterada pode ser perfeitamente válida para o parser.

Cada resposta HTTP comprova uma etapa

Em HTTP/1.1, o cliente usa GET na URI expandida e pede Upgrade: connect-tcp. Se a requisição for bem formada e permitida, o proxy tenta a conexão TCP antes de qualquer resposta final. Com sucesso, envia 101 Switching Protocols; sem TCP estabelecido, não pode trocar de protocolo.

Em HTTP/2 e HTTP/3, o proxy anuncia extended CONNECT. O cliente usa :protocol = connect-tcp, coloca o proxy em :authority e usa o path e o scheme derivados do modelo. Uma resposta CONNECT bem-sucedida abre o fluxo para o Capsule Protocol.

Expect: 100-continue mostra um recibo anterior: o 100 confirma recebimento e ausência de rejeição imediata, sem esperar o handshake com o destino. O 101 ou o sucesso do extended CONNECT confirma que o proxy relata uma conexão TCP estabelecida. Isso não autentica o aplicativo remoto, não valida o TLS do destino, não prova entrega nem confirma que a operação terminou.

Portanto, telemetria não deve resumir tudo como “conectado”. Rejeição de política, falha no estabelecimento e erro de aplicação dentro do túnel pertencem a camadas distintas.

A autenticação continua limitada ao proxy

Como o serviço tem origem própria, a autenticação normal usa 401, WWW-Authenticate e Authorization. A revisão não usa o 407 clássico porque seus campos não atravessam gateways HTTP comuns. Recursos gerados por um modelo compartilham normalmente um protection space; certificados TLS de cliente também são possíveis.

O ganho operacional é concreto. O proxy pode ficar atrás de roteamento por caminho, defesa DDoS, sanitização de requisições e autorização de usuários. Um caminho de alta entropia ou autenticação oculta pode reduzir a descoberta por clientes sem permissão.

Mas uma credencial aceita responde a uma pergunta estreita: aquele principal satisfez o esquema de autenticação do protection space? Outra regra precisa autorizar host e porta. A resolução DNS escolhe endereços. O TLS remoto avalia a identidade do serviço. O aplicativo decide a ação que o usuário pode executar.

O RFC 9110 alerta que CONNECT aberto a portas arbitrárias pode transformar o proxy em retransmissor de protocolos indevidos. O modelo não elimina esse risco; oferece um local mais claro para aplicar a política.

A ordem dos bytes não é o resultado da aplicação

O payload TCP viaja em cápsulas DATA. FINAL_DATA pode levar os últimos bytes e também representa o FIN daquela direção. Depois dela, não pode haver novo DATA nem outro FINAL_DATA. FIN recebido do TCP deve gerar FINAL_DATA; FINAL_DATA válido deve gerar FIN no TCP.

As bordas das cápsulas não precisam coincidir com segmentos TCP, registros TLS, frames HTTP ou mensagens da aplicação. Intermediários podem unir ou dividir cápsulas sucessivas desde que preservem a ordem e o tipo da última cápsula.

O contrato comum preserva sequência e meia-finalização. Não preserva significado de negócio. O cliente pode ter escrito no fluxo enquanto o proxy ainda segura dados otimistas. O proxy pode ter escrito no socket sem que o aplicativo tenha processado. FINAL_DATA pode carregar o FIN de ida e ainda assim a volta terminar em reset.

Em HTTP/2 e HTTP/3, dados otimistas devem ficar em buffer até que a conexão escolhida aceite escrita e precisam ser descartados se ela falhar. Na corrida entre endereços, as conexões perdedoras não podem receber payload. A auditoria deve separar modelo, identidade TLS do proxy, autenticação, política, DNS, tentativa TCP, status HTTP, DATA/FINAL_DATA, TLS do destino, bytes, fechamento e resultado observado.

Last Call descreve processo, não adoção

O anúncio do IESG pede comentários até 1º de outubro. O Datatracker mostra a revisão 14 ativa, submetida ao IESG e destinada a Proposed Standard.

O processo ainda pode alterar, substituir ou deixar expirar o texto. Mesmo um RFC futuro comprovaria um contrato de interoperabilidade, não código em produção, suporte do gateway, testes de half-close ou política segura.

A primazia do código em execução exige evidência do sistema que suporta a consequência. A especificação inicial mínima ajuda a limitar o plano comum a sintaxe, ordem, encerramento e erro. Confiança no provisionamento, destinos aceitos e critério de sucesso continuam decisões locais.

O proxy pode autorizar o túnel. Não pode transformar esse aceite em verdade sobre tudo o que acontece depois.

Fontes