Resumo

  • Um frame ORIGIN permite ao servidor HTTP/2 indicar origens que um cliente compatível pode associar à conexão.
  • A inclusão no Origin Set continua condicionada a um certificado válido para a origem nomeada; o frame não substitui essa verificação.
  • A validade é específica da conexão em que foi recebido; entradas inválidas e frames vindos de proxy, fluxo ou protocolo incorretos são ignorados.
  • A prova de reúso liga frame válido, origem exata, decisão do certificado, escolha do cliente, solicitação e eventual remoção por 421.

Imagine uma plataforma compartilhada enviando ORIGIN com um segundo serviço HTTPS. O painel vê o nome numa captura e elimina o teste de conexão dedicado. O certificado compartilhado não contém o nome. Esse cliente deixa de reutilizar a conexão e abre outra. Em um teste independente com estado desatualizado, outra instância envia a solicitação pela conexão anterior e recebe 421 Misdirected Request. O frame foi recebido, mas não bastava para atender a segunda origem.

Esse cenário é hipotético, não um incidente atribuído. O erro é fundir afirmação do servidor, decisão do cliente e resultado da solicitação.

O frame altera um conjunto associado à conexão

RFC 8336 define ORIGIN como extensão HTTP/2 que inicializa ou modifica o Origin Set do cliente compatível. Cada entrada serializa uma origem específica; não é curinga, redirecionamento ou nova identidade.

O frame deve estar no fluxo 0 e em h2 ou protocolo que o adote, sendo ignorado em h2c. É não crítico. Seu efeito vale apenas na conexão em que foi recebido: intermediários não o encaminham e clientes com proxy ignoram frames recebidos dele. Sem conexão, protocolo, fluxo e remetente, uma captura não prova processamento.

Entradas que não podem ser analisadas são ignoradas. ORIGIN não aceita nomes curingas; cada origem precisa ser explícita. Cobertura de certificado curinga e Origin Set são listas diferentes.

Estar no Origin Set não basta

Após inicialização, o conjunto limita o reúso: o cliente não deve usar a conexão para uma origem ausente. A presença também não basta. RFC 8336 exige certificado aprovado em verificações adequadas, incluindo correspondência do host com subjectAltName.

RFC 9110 vincula autoridade HTTPS a conexão segura estabelecida e certificado confiável para a origem. Uma entrada ORIGIN não cria confiança, amplia nomes do certificado ou elimina política do cliente.

R065 também não repete R064. Alt-Svc indica outro caminho de serviço; ORIGIN descreve origens associadas a uma conexão. RFC 8336 diz que anúncios alternativos não mudam o Origin Set nem determinam autoridade.

A autoridade pode mudar

Frames válidos posteriores adicionam entradas. 421 Misdirected Request faz o cliente compatível remover a origem correspondente. A declaração anterior não vale para sempre.

O cliente pode evitar DNS em alguns casos, mas RFC 8336 aponta risco adicional e pede alta confiança na legitimidade do certificado por outros meios. Isso é escolha de política, não comportamento comprovado de todos.

Valide a mudança apenas com um registro completo sobre o uso da conexão para aquela origem: identidade, protocolo, fluxo, bytes, remetente, análise e ordem do conjunto. Para cada origem, vincule cadeia do certificado, confiança, SAN exato, evidência DNS quando usada, decisão de reúso, resultado da solicitação e remoção 421. Restrinja a conclusão à população e janela observadas.

Fontes