Resumo

  • O CONNECT tradicional identifica o destino TCP, mas não dá ao serviço de proxy uma origem e um caminho próprios. O novo modo usa um modelo de URI e transporta o fluxo em mensagens Capsule.
  • O IESG aprovou o rascunho para publicação como Proposed Standard em 30 de outubro. Gateways compatíveis terão de converter o túnel entre as versões HTTP que atendem; o registro público não traz contagens de implantação nem resultados de campo.

O proxy ganhou endereço. O gateway ganhou tarefa.

Há anos, o HTTP CONNECT permite que um cliente peça a um proxy uma conexão TCP com determinado host e porta. O proxy passa os bytes entre o cliente e esse destino. A requisição, porém, identifica para onde vai o túnel, não qual serviço de proxy o atende. Faltam ao próprio serviço origem e caminho explícitos.

A lacuna aparece quando um servidor HTTP hospeda vários serviços de proxy. Sem origem ou caminho próprios, ele não os distingue como distingue recursos web ou hosts virtuais. O rascunho aponta também um efeito de segurança: sem uma origem explícita do proxy, as defesas usuais contra confusão de portas no servidor não se encaixam; o alcance de cabeçalhos como Alt-Svc e Strict-Transport-Security fica indefinido.

Em 30 de outubro, o IESG aprovou draft-ietf-httpbis-connect-tcp para publicação como Proposed Standard. A versão 17 do texto saiu no dia anterior. Ela propõe uma nova forma de transportar TCP por HTTP, não uma decisão sobre quais destinos um usuário pode alcançar. O serviço de proxy passa a ter endereço mais claro. A autorização continua com quem opera o proxy.

O rascunho identifica o serviço por um modelo de URI com target_host e target_port. O cliente substitui os campos pelo destino e envia a URI resultante ao proxy. No HTTP/1.1, usa GET e faz Upgrade para connect-tcp. No HTTP/2 e no HTTP/3, usa Extended CONNECT com :protocol definido como connect-tcp. O proxy anuncia nos parâmetros se oferece esse suporte.

O fluxo TCP viaja em mensagens do Capsule Protocol. DATA carrega bytes; FINAL_DATA carrega os bytes finais e sinaliza o encerramento equivalente a FIN do TCP. Os limites das cápsulas não imitam segmentos TCP ou registros TLS. São a embalagem do fluxo enquanto ele cruza o HTTP.

Com origem e caminho definidos, o serviço de proxy ganha lugar nas semânticas normais do HTTP. Um servidor pode distinguir seus serviços, e cabeçalhos vinculados à origem passam a ter escopo. A autorização permanece separada: o proxy ainda precisa definir que destinos permite. Modelo de URI não é lista de controle de acesso.

A conta chega aos gateways. Quem prometer compatibilidade precisa lidar com Upgrade no HTTP/1.1 ou Extended CONNECT, encaminhar connect-tcp e converter a requisição entre as versões HTTP que suporta. Também precisa deixar Proxy-Status passar. Se o servidor de destino autenticar clientes por certificado TLS, o gateway precisa fazer essa autenticação ou encaminhar as informações do certificado.

O IETF escreveu essa transferência de responsabilidade nos requisitos. Não atualizou os gateways. O rascunho e o registro da decisão não informam quantos gateways estão implantados, qual seria a adoção ou quais foram os resultados de interoperabilidade em produção. Um padrão pode fixar o formato da mensagem; os operadores ainda têm de encontrar cada proxy, intermediário e fronteira de autenticação no caminho.

Fontes