Resumo

  • PTTH permite ao cliente de transporte abrir um canal pelo qual o proxy depois envia pedidos HTTP ao worker.
  • A carta proposta inclui autenticação e autorização; uma conexão de saída não concede acesso irrestrito.

O backend abre a conexão. Depois, o proxy o chama de volta.

Essa é a ideia de Protocol for Transposed Transactions over HTTP, ou PTTH: um worker atrás de firewall restritivo inicia uma conexão de saída até o proxy, que pode enviar pedidos HTTP por esse canal. O cliente de transporte recebe os pedidos no papel de servidor HTTP.

Isso pode evitar portas de entrada para cada worker e endereços fixos para cada backend. Mas a decisão difícil só muda de lugar: depois que o canal existe, o que o proxy pode pedir ao worker?

A carta proposta para um grupo do IETF está em revisão externa e consta da teleconferência do IESG de 5 de novembro de 2026. Em 2 de novembro, ainda é uma proposta; não existe padrão PTTH aprovado.

No IETF 123, em julho de 2025, foram apresentados backends ocultos, expansão dinâmica de CDN, prioridade de pedidos, acesso Zero Trust e HTTP como base para outros protocolos. Um worker de CDN limitado a certos caminhos não equivale a um túnel genérico.

As atas registram a disputa sobre poder: se o worker enviar configuração ao proxy, pode influenciar o roteamento. Os participantes questionaram autenticação, limites dentro do espaço de URLs e a fronteira entre HTTP e um meio para outros protocolos. As votações apoiaram continuar no IETF, mas não mediram demanda nem definiram o escopo.

No IETF 126, em julho de 2026, a discussão separou abertura do canal, autorização dos pedidos e gestão de capacidade. As duas primeiras eram essenciais para o início; capacidade e controle dependiam mais de cada implantação. Também voltou a preocupação com o poder do worker sobre o proxy.

A carta proposta inclui declarar disponibilidade para receber pedidos, autenticar os dois lados, definir os pedidos autorizados e orientar o roteamento. Ainda está em aberto se as duas pontas poderão enviar pela mesma conexão. Novos sistemas de identidade, transporte e descoberta, pedidos de capacidade e mudanças na semântica HTTP ficam fora.

O canal resolve conectividade, não admissão, rota ou revogação. Regras próprias de cada fornecedor deixam um mosaico ao operador. Um padrão amplo demais pode transformar um caminho útil em atalho entre fronteiras de confiança.

Avalie o conjunto: worker autenticado, pedidos permitidos, decisão do proxy, expiração ou revogação e registro auditável. Sem isso, um túnel funcionando prova transporte, não autorização.

Fontes: carta PTTH proposta pelo IETF; atas do IETF 123; atas do IETF 126; rascunho individual PTTH.