Resumo

  • Uma resposta 103 antecipa campos que provavelmente aparecerão na resposta final. Ela pode sustentar preparação reversível, como buscar um recurso indicado para preload, mas o resultado final ainda pode retirar, trocar ou acrescentar campos.
  • O cliente precisa definir seu próprio orçamento para errar. A dica não autentica sua origem, não concede autorização, não fixa a política de cache e não pode iniciar efeitos irreversíveis.

O valor de Early Hints nasce de uma condição desconfortável: a informação chega cedo porque ainda não está completa. Se o servidor já soubesse cada campo e o status definitivo, poderia simplesmente enviar a resposta final. O código 103 existe para o intervalo em que uma parte do futuro parece provável, embora o futuro ainda possa mudar.

A RFC 8297 dá forma a esse intervalo. Enquanto uma aplicação executa uma operação demorada, ela pode enviar cabeçalhos que espera repetir mais tarde. Um cliente que reconhece um Link com relação preload pode começar a buscar uma folha de estilo ou outro recurso. O tempo antes ocioso passa a produzir trabalho útil.

Essa vantagem desaparece quando o receptor transforma previsão em ordem. A especificação mantém os papéis separados: o emissor oferece uma estimativa; o cliente decide se vale a pena agir; a resposta final estabelece o resultado.

O HTTP preserva a ordem dos graus de certeza

Segundo a RFC 9110, uma requisição pode receber zero ou mais respostas informativas 1xx antes de uma resposta final que não seja 1xx. A resposta informativa termina no fim da seção de campos e não possui conteúdo nem trailers. O cliente deve conseguir analisar uma ou várias respostas 1xx mesmo sem esperá-las; um agente de usuário, porém, pode ignorar respostas inesperadas.

O status 103 ocupa exatamente essa etapa. Ele informa que o servidor provavelmente enviará, na resposta final, os campos apresentados cedo. Em geral eles se repetem. Ainda assim, o servidor pode descobrir durante o processamento que um campo estava errado ou deixou de ser desejável.

Por isso, a RFC 8297 declara que os campos antecipados são apenas indícios e não substituem os campos finais. Fora das otimizações de desempenho, avaliá-los não pode alterar a maneira como o resultado definitivo será processado. Eles também não descrevem o próprio 103 como se fosse uma representação autônoma.

Um dos exemplos envia dois blocos 103. Juntos, eles anunciam três links; no final, dois permanecem e um é trocado por outro. A divergência não representa quebra de contrato. Ela demonstra que o contrato aceita correção.

Uma arquitetura interna deveria conservar essa sequência em vez de despejar todos os campos em um objeto chamado “resposta provisória”. O nome sugere algo quase definitivo. O que existe, na realidade, são previsões ordenadas e, depois, uma resposta de natureza diferente.

Silêncio inicial não remove uma regra posterior

O servidor pode antecipar apenas alguns campos. Quando novas informações aparecem, pode mandar vários 103 e não precisa repetir o que já havia enviado. O cliente pode considerar a combinação recebida, mas não deve tomar a ausência de um campo como sinal de que ele será improvável na resposta final.

Essa assimetria impede conclusões perigosas. Se o primeiro 103 não traz instruções de cache, desafio de autenticação ou determinada política de segurança, o cliente não ganha o direito de agir como se o final também não as trouxesse. O canal faz afirmações positivas e parciais; ele não nega por omissão.

Exigir uma lista completa antes do envio pareceria mais seguro, porém eliminaria a oportunidade. O servidor precisaria concluir justamente o processamento que o 103 pretende sobrepor à busca do recurso. A incompletude não é acidente; é a condição que a política local precisa administrar.

Assim, a pergunta correta não é se a dica é “confiável” em abstrato. A pergunta é quanto custa uma previsão errada. Uma busca cancelável de um arquivo público tem perfil diferente de reservar estoque, alterar uma conta, revelar um segredo ou movimentar dinheiro.

preload descreve uma relação, não uma obrigação

Web Linking fornece uma linguagem para relacionar um alvo ao contexto da resposta. A relação preload permite que um cliente apto reconheça a utilidade potencial de buscar o recurso antes de receber a representação completa.

Nada obriga todos os clientes a reagir do mesmo modo. Um aparelho com franquia limitada pode ignorar o campo. Um navegador pode aceitar apenas certos destinos ou tipos de recurso. Uma organização pode impedir especulação entre origens. A semântica é compartilhada; a decisão de gastar recursos continua local.

Buscar antecipadamente tem consequências concretas. Consome banda, ocupa conexões, alcança outro serviço, modifica caches e revela interesse em um endereço. Dependendo das regras normais da plataforma, credenciais também podem entrar na requisição. Receber o campo alguns instantes antes não revoga controles de origem, modo, autorização, tamanho ou privacidade.

A resposta final pode ser um erro, um redirecionamento ou um desafio de autenticação. Ela pode omitir o link antecipado. Mesmo que o download termine, isso não prova que o objeto deva ser executado, exibido ou usado.

A fronteira adequada é esta: 103 pode adiantar um trabalho que já era permitido por outra política. O indício não cria a permissão de que precisa.

A borda também faz previsões

A autoria do primeiro campo observado pode ser menos simples do que parece. A RFC 8297 descreve um intermediário de cache que gera 103 usando campos de uma resposta armazenada e já obsoleta. Enquanto revalida, ele pode encaminhar outro 103 e a resposta final recebidos do servidor de origem.

O cenário aproveita conhecimento próximo do usuário para reduzir latência. Ao mesmo tempo, mostra que a dica inicial pode representar a memória do intermediário, não o julgamento atual da aplicação. O cliente não deve usar a mera chegada do campo como prova de autoria da origem.

A RFC 9110 normalmente obriga um proxy a encaminhar respostas 1xx, exceto quando o próprio proxy solicitou a geração daquela resposta informativa. A obrigação garante transporte. Não transforma quem encaminha em autoridade sobre o significado final.

Operadores de CDN, gateway e aplicação precisam indicar qual camada pode sintetizar 103, qual estado de cache utiliza, quão antigo ele pode ser e como uma previsão será comparada com o final. Como o cliente nem sempre vê toda a cadeia, seu conjunto de ações antecipadas deve continuar seguro sob procedência ambígua.

As métricas também precisam atribuir a previsão à camada possível. Agrupar tudo como “dica do servidor” esconde uma borda desatualizada atrás de mudanças que a aplicação nunca fez.

Confundir o provisório pode quebrar a conexão

A seção de segurança da RFC 8297 alerta para clientes HTTP/1.1 que tratam uma resposta informativa como final. Em uma conexão persistente, eles podem passar a interpretar respostas a requisições posteriores como parte da resposta anterior. Se a conexão carregar pedidos de origens diferentes, a confusão pode causar divulgação entre origens.

Portanto, “informativa” não é apenas uma qualificação editorial. Faz parte da delimitação de mensagens. A RFC 9112 manda associar cada resposta recebida à primeira requisição pendente que ainda não obteve uma resposta final não-1xx. Só há mais de uma mensagem de resposta para uma requisição quando uma ou mais informativas antecedem o final.

A RFC 8297 admite que um servidor deixe de enviar 103 sobre HTTP/1.1 quando não conhece a capacidade do cliente de tratar respostas informativas. Ela considera o erro específico de enquadramento menos provável em HTTP/2, onde respostas provisórias são blocos de campos em um fluxo e um bloco informativo não pode encerrá-lo. A RFC 9114 mantém para HTTP/3 a possibilidade de vários 1xx antes do final e exclui conteúdo e trailers dessas mensagens.

Enquadramento moderno reduz uma classe de falha, não o abuso semântico. Um cliente pode analisar HTTP/3 corretamente e ainda assim tratar um indício como consentimento. Integridade de transporte e autoridade de negócio são controles complementares.

Cache fornece evidência antiga, não decisão atual

O cache consegue agir cedo porque guarda o passado. A evidência pode ser boa e, mesmo assim, estar vencida. Um script usado na página anterior pode ter sido retirado; a revalidação pode produzir outro status; a nova representação pode escolher dependências diferentes.

A RFC 9111 separa frescor, validação, armazenamento e reutilização. O download iniciado por 103 não determina se a resposta final é armazenável, fresca ou aplicável à requisição atual. Aquecer um objeto também não obriga a representação final a referenciá-lo.

É útil registrar eventos distintos: dica emitida, recebida, reconhecida, busca iniciada, campo confirmado no final e recurso efetivamente consumido. Uma única taxa de sucesso apaga bytes descartados, buscas duplicadas, pressão sobre conexões, exposição de privacidade e carga imposta à origem.

Os incentivos divergem. A página recebe o benefício de uma renderização mais rápida, enquanto o usuário paga tráfego desperdiçado. A borda procura reutilizar seu cache; a origem pode absorver acessos desnecessários. O orçamento controlado pelo cliente impede que uma otimização local transfira seu custo em silêncio.

Um mínimo comum comporta escolhas diferentes

O registro da IANA associa 103 a Early Hints e aponta para a RFC 8297. Publicado em 2017, o documento é um protocolo Experimental da IETF. Ele expressa consenso da comunidade, passou por revisão pública e recebeu aprovação do IESG, mas não integra a Internet Standards Track. Essa maturidade deve acompanhar qualquer recomendação de adoção.

O acordo comum é pequeno: um status intermediário, campos HTTP normais, posição anterior ao resultado e uma regra de não substituição do final. Sobre esse piso, políticas diferentes permanecem interoperáveis. Um navegador reconhece relações específicas; um dispositivo restrito ignora tudo; uma empresa proíbe destinos externos; um cache gera dicas apenas quando seu histórico recente justifica.

Essa forma segue a sequência de Lu Heng: especificação inicial mínima, decisões futuras localizadas e adoção voluntária informada. O servidor conhece o andamento de sua computação. O intermediário conhece a idade de seu cache. O cliente conhece seu custo de rede, suas credenciais e os riscos que assume. Cada decisão fica perto da evidência relevante.

Uma central de autorizações para cada dica consumiria a própria latência que se pretende economizar. A alternativa não é ausência de regras. É uma política local pronta antes da requisição: relações reconhecidas, origens permitidas, limite de bytes, tratamento de credenciais e efeitos que jamais podem começar cedo.

Manter um livro de apostas, não uma resposta fantasma

Uma implementação responsável guarda cada 103 em ordem e separadamente do final. Ela vincula o bloco que iniciou uma busca à requisição, à versão HTTP e à regra local aplicada. Uma nova dica não apaga a antiga.

Depois, classifica os efeitos pela perda possível. Recursos públicos, limitados e descartáveis podem receber orçamento. Mudança de estado, transferência de valor, exposição de informação, consentimento e alteração de acesso esperam a autoridade normal.

Quando o final chega, ocorre reconciliação: quais campos se repetiram, sumiram ou mudaram; quais tarefas ainda são úteis; quais devem ser canceladas; quanto tempo foi ganho e quanto recurso foi perdido. O processamento segue os campos finais, enquanto o histórico precoce explica o desempenho.

Também deve existir a opção simples de ignorar. Se uma versão, intermediário ou rede se torna inseguro, o cliente suspende a ação em 103 sem deixar de tratar corretamente as respostas finais.

Early Hints não adivinha o futuro. Ele permite que uma previsão declaradamente incompleta financie preparação limitada. A disciplina serve além do HTTP: compartilhar cedo, limitar localmente a perda e reservar a palavra final para a decisão que terminou de reunir os fatos.

Fontes