Resumo

  • O HTTP/2 permitiu que uma conexão persistente e multiplexada carregasse requisições para diferentes autoridades de URI quando DNS e certificado forneciam evidência suficiente. Essa verificação justificava a tentativa do cliente, mas não revelava toda a seleção interna de serviço feita pelo SNI da primeira negociação.
  • 421 Misdirected Request recusa a associação entre uma origem e uma conexão. Não afirma que o URI mudou, que a requisição está malformada nem que o TLS necessariamente falhou. O cliente pode repetir a mesma operação em outra conexão, inclusive se o método não for idempotente; um proxy comum não pode gerar o status.
  • A RFC 8336 criou o quadro ORIGIN para anunciar antecipadamente o Origin Set de uma conexão HTTP/2 e fazer o cliente compatível remover dele uma origem após receber 421. O HTTP/3 conservou o código sobre QUIC, mostrando que a questão duradoura é a autoridade em um transporte compartilhado.

O certificado comportava dois nomes

Um cliente já abriu uma conexão criptografada para a primeira origem. A segunda origem resolve para o mesmo endereço, e seu nome também aparece entre as identidades aceitas no certificado apresentado. Abrir outra conexão repetiria negociação, criaria mais estado e acrescentaria espera. Usar a existente parece ser exatamente o tipo de economia que o HTTP/2 pretendia oferecer.

Ainda assim, a prova externa não descreve todo o interior. O SNI enviado quando a conexão foi estabelecida pode ter escolhido um locatário, um terminador TLS, uma política de porta ou um conjunto de servidores de origem. Um certificado pode autenticar corretamente dois nomes, enquanto o caminho interno selecionado para o primeiro atende apenas um deles.

A segunda origem talvez responda normalmente quando uma nova conexão é aberta com o seu próprio nome no SNI. A conexão antiga também pode continuar perfeita para a primeira. O defeito está na proposição que ligou a segunda origem ao contexto da primeira conexão.

O cliente tinha evidência para tentar. O servidor tinha evidência local para rejeitar. O 421 permitiu que a diferença fosse resolvida sem transformar nenhum dos lados em erro absoluto.

Host informou o destino sem nomear o respondente

O HTTP já havia separado endereço de transporte e espaço de nomes. Quando muitos sites passaram a compartilhar um endereço IP, o destino TCP deixou de dizer qual deles o cliente pretendia acessar. O HTTP/1.1 tornou Host obrigatório; no HTTP/2 e no HTTP/3, :authority normalmente expressa a mesma informação.

Isso responde “qual origem o cliente quer?”. Não responde “este serviço, nesta conexão, está configurado para falar por ela?”.

A RFC 9110 mantém as duas etapas. Host e porta do URI alvo distinguem uma origem dos demais espaços que o servidor pode controlar. Depois de identificar o alvo, porém, o servidor ainda decide se processa, encaminha, redireciona, rejeita ou encerra, e precisa conferir as exigências do esquema e do contexto da conexão.

Host registra intenção. Não transforma cada processo alcançável pelo socket em representante obrigatório daquele nome.

O HTTP/2 tornou o palpite economicamente relevante

A especificação original do HTTP/2, RFC 7540, foi publicada em maio de 2015. Conexões persistentes e múltiplos fluxos simultâneos deram grande valor ao reuso. Uma conexão poderia receber requisições com componentes de autoridade diferentes se o servidor de origem parecesse ter autoridade para eles.

Em TCP sem TLS, a regra dependia de o novo host resolver para o mesmo endereço IP. Em HTTPS, o certificado também precisava ser válido para o novo host segundo as verificações que seriam feitas ao criar uma conexão nova. Vários subjectAltName, ou um curinga aplicável, podiam fazer uma credencial cobrir diversas origens.

Essas condições impediam um compartilhamento sem critério. Eram, contudo, provas disponíveis ao cliente. Não expunham necessariamente como o tráfego seria distribuído depois da terminação TLS.

A RFC 7540 descreveu o caso de um intermediário que usa o SNI da negociação para escolher um servidor de origem. Uma requisição posterior a outro nome coberto pelo certificado pode chegar ao contexto errado, embora a infraestrutura, em sentido amplo, consiga servir esse nome. DNS e certificado podem estar corretos, e a mensagem HTTP pode ser válida. O cliente apenas não vê a última decisão de encaminhamento.

O servidor que recebeu a requisição vê essa decisão. O 421 lhe deu uma resposta proporcional a ela.

O status recusou uma relação, não a origem

421 Misdirected Request nasceu na RFC 7540. Sua definição atual está na RFC 9110, entre as semânticas gerais do HTTP. O servidor sinaliza que não consegue ou não quer produzir uma resposta com autoridade para o URI alvo.

O alvo pode não corresponder a nenhuma origem configurada no serviço. Também pode não corresponder ao contexto da conexão pela qual chegou.

O status não diz que o recurso foi removido, nem que a origem mudou de endereço. Não manda substituir o URI. Também não precisa inutilizar a conexão para outras origens. Ele rejeita a combinação “esta origem por esta conexão”.

Um servidor de origem pode emitir 421. Um gateway que atua em nome da origem também pode. Um proxy não pode gerar o status, segundo a RFC 9110. A restrição preserva a procedência do julgamento: ele deve vir da fronteira que conhece a configuração da origem, e não de qualquer nó de encaminhamento que prefira outro caminho.

Evidência negativa sem origem confiável seria apenas uma nova fonte de ambiguidade.

Alcance, identidade e aceitação são provas diferentes

Três afirmações costumam ser confundidas. A conexão alcança um endpoint. O endpoint se autentica com um certificado aceito para a origem. A implantação aceita produzir a resposta da origem no contexto específico dessa conexão.

As duas primeiras tornam o reuso razoável. Não tornam a terceira obrigatória. Um certificado comprova controle de uma chave privada para identidades reconhecidas; não comprova que cada identidade pertence ao mesmo locatário, aplicativo, pool de origem, porta ou política em toda conexão que o apresenta.

Também não é correto concluir, após um 421, que o certificado se tornou inválido ou que a origem deixou de existir. As provas continuam verdadeiras dentro dos seus limites. O que falhou foi a passagem automática de uma para a outra.

O 421 dá ao lado receptor um veto estreito sobre a aceitação do contexto. Justamente por ser estreito, ele não destrói o valor das demais evidências.

Repetir em outra conexão corrigia o contexto

O cliente que recebe 421 pode repetir a requisição em outra conexão, como uma conexão nova e específica para a origem ou uma conexão por um serviço alternativo. A permissão vale mesmo quando o método não é idempotente.

Isso não cria uma regra geral de que gravações podem ser repetidas após qualquer falha de rede. O significado específico do 421 é que o respondente recusou produzir a resposta com autoridade naquele contexto. Trocar a conexão procura corrigir a entrega antes que o serviço certo trate a operação; não é o mesmo que repetir depois de um resultado de aplicação desconhecido.

Mesmo assim, o cliente pode decidir não tentar. O corpo talvez não possa ser reproduzido, credenciais podem estar vinculadas ao canal, uma política local pode exigir confirmação ou a aplicação pode preferir evitar qualquer risco. A norma oferece uma faculdade, não uma obrigação.

Para que haja recuperação, uma condição precisa mudar. Reenviar indefinidamente pela conexão já recusada apenas cria um laço. O URI, o método e a intenção permanecem. A nova conexão, ainda que termine no mesmo endereço e veja o mesmo certificado, pode levar o SNI correto e selecionar outro contexto interno.

O significado da operação é preservado; seu veículo é reavaliado.

Não era um redirecionamento oculto

Um redirecionamento propõe outro alvo e normalmente fornece um Location. Pode mudar host, caminho, autoridade, chaves de cache e escopo de credenciais. O 421 não oferece um URI substituto.

Tratado como redirecionamento, ele permitiria que uma inconsistência interna mudasse a identidade pública do pedido. Credenciais poderiam ser enviadas a outra autoridade, nomes internos poderiam vazar e um mapa de serviço defeituoso pareceria uma mudança legítima de recurso.

O 421 também não é 400 Bad Request, pois a sintaxe da requisição pode estar correta. Não é 403 Forbidden, porque o centro do problema não é a permissão do usuário. E não é um alerta TLS: a validação pode ter sido bem-sucedida e ter motivado a própria tentativa de reuso.

Um código específico impede que o vocabulário de uma camada tome poder sobre o significado das outras.

ORIGIN antecipou parte da decisão

Descobrir o problema por um 421 custa tempo: a requisição já foi enviada. A RFC 8336, de março de 2018, definiu o quadro HTTP/2 ORIGIN para que o servidor anunciasse as origens para as quais uma conexão pode ser usada.

O conjunto é o Origin Set da conexão. Depois de inicializado, um cliente compatível não deve considerar a conexão com autoridade para uma origem que não esteja nele. As entradas precisam ser origens explícitas; curingas não são admitidos. Assim, um certificado curinga não vira silenciosamente uma lista operacional ilimitada.

ORIGIN descreve uma propriedade do enlace e é processado salto a salto. Um intermediário não encaminha o quadro, e um cliente configurado com proxy ignora o que recebe dele. O servidor pode acrescentar origens posteriormente, mas o cliente continua obrigado a validar o certificado. O anúncio não é uma nova credencial.

Quando recebe 421, um cliente que implementa a RFC 8336 remove a origem correspondente do Origin Set daquela conexão. A recusa passa a corrigir futuras escolhas em vez de ser esquecida como uma página de erro.

O escopo da memória é decisivo. Bloquear a origem em todas as conexões aprenderia demais com um fato local. Não memorizar nada repetiria o mesmo erro. Origem e conexão precisam formar a chave.

Alt-Svc apontava uma alternativa sem se autorizar sozinho

Alt-Svc permite que uma origem anuncie outro host, porta ou protocolo como serviço equivalente. A recuperação de um 421 pode escolher esse caminho. O anúncio, porém, não elimina as verificações de autoridade nem modifica sozinho o Origin Set.

DNS fornece uma razão sobre alcance. O certificado fornece identidade. Alt-Svc nomeia uma alternativa. ORIGIN declara intenção de uso de uma conexão. O receptor conhece o contexto realmente selecionado. Cada sinal tem uma função limitada.

Se uma dessas peças pudesse provar todas as outras, a cadeia se tornaria uma autorização circular. A possibilidade de 421 preserva uma verificação no ponto que enxerga a combinação final.

Sinais estreitos podem colaborar sem criar um soberano único.

O HTTP/3 trocou o transporte, não a fronteira

A especificação HTTP/2 vigente, RFC 9113, substituiu a RFC 7540, mantendo o reuso entre origens e o 421. A RFC 9114 mapeou o HTTP sobre QUIC e também preservou o status.

Conexões HTTP/3 continuam persistentes e podem ser reutilizadas para diferentes autoridades de URI. Antes de usar uma conexão existente para uma origem nova, o cliente precisa validar o certificado contra essa origem. Se ele não for aceitável, o reuso é proibido. Mesmo quando é aceitável, o servidor pode responder 421 se não quiser que aquela conexão sirva a origem específica.

O percurso histórico esclarece o princípio. O código nasceu dentro do HTTP/2, migrou para a semântica independente de versão e continuou no HTTP/3. O problema não era o TCP nem um formato de quadro. Ele reaparece sempre que um canal eficiente parece poder falar por vários nomes enquanto o receptor conserva informação de contexto que o emissor não possui.

Mudar os pacotes não muda a pergunta sobre autoridade.

O evento observável é a aresta rejeitada

Um contador agregado de 421 não explica qual relação falhou. É preciso registrar esquema, host e porta alvo; método; versão HTTP; identificadores de conexão e fluxo; endpoint remoto; SNI; ALPN; identidades do certificado; resultado DNS usado na decisão; origem do Alt-Svc; Origin Set; frontal e backend selecionados; papel de quem respondeu; nova conexão e resultado do reenvio.

Se a conexão compartilhada recebe 421 e uma conexão específica funciona, a seleção de contexto é a hipótese principal. Se ambas recebem 421, a origem pode estar ausente da configuração em geral. Se apenas uma região falha, anúncios, certificados e servidores podem ter convergido em momentos diferentes.

Um 421 isolado pode representar uma correção saudável de uma aposta de desempenho. O problema é uma recusa que se repete sem que o cliente ou o operador mudem a condição.

Compartilhar transporte não era compartilhar governo

O reuso economiza negociações, estado e latência. O 421 não nega esses benefícios nem exige uma conexão exclusiva por nome. Ele torna a otimização revogável.

O cliente decide tentar com a evidência que consegue observar. O receptor decide se SNI, locatário, porta e backend realmente podem falar pela origem. Em caso de desacordo, o URI e a operação ficam intactos, enquanto o contexto é trocado.

Sem um veto específico, a primeira conexão poderia adquirir autoridade de fato sobre todo nome coberto pelo certificado compartilhado. Uma escolha de desempenho se tornaria uma concentração do controle de serviço.

O registro de códigos de status HTTP da IANA mantém 421 como Misdirected Request e aponta para a RFC 9110. O registro fixa um nome e uma referência interoperáveis; não comprova frequência de uso, reenvio por todos os clientes nem correção da configuração de uma implantação específica.

A conexão era válida. A segunda origem também. O que não existia era o mandato da primeira para responder pela segunda. O 421 manteve estreita essa autorização mesmo quando o canal ficou largo.