Resumo

  • A RFC 9111 permite combinar falhas em uma requisição encaminhada somente quando a resposta pode ser reutilizada para as requisições envolvidas.
  • Cada requisição em espera preserva sua própria decisão sobre alvo, método, campos Vary, autorização e controles do cache.

Imagine um gateway de borda em um caso explicitamente hipotético. Duas requisições GET para o mesmo URI chegam quase juntas. Uma é anônima; a outra contém Authorization e espera uma representação específica da conta. O gateway escolhe a primeira como requisição principal, consulta a origem uma vez e entrega o mesmo 200 OK às duas. Poupa capacidade, mas faz a decisão da segunda requisição desaparecer dentro da otimização.

A RFC 9111 admite a combinação por um motivo prático. Quando várias requisições falham no cache ao mesmo tempo, uma consulta encaminhada reduz carga na origem e na rede. A permissão tem condição: a resposta retornada precisa poder ser usada nas requisições em questão. Se não servir para algumas ou todas, elas precisam ser encaminhadas, ainda que isso acrescente latência.

Essa condição é essencial porque semelhança de URI não basta. O URI-alvo deve coincidir; o método associado à resposta armazenada precisa permitir a reutilização; os campos indicados por Vary devem corresponder; condições no-cache precisam ser cumpridas; e a resposta deve estar fresca, poder ser servida obsoleta ou ter sido validada. A combinação muda o número de buscas, não as condições de cada requisição.

Vary compõe a decisão. A RFC 9110 afirma que ele nomeia campos da requisição que podem ter influenciado a seleção da representação, ampliando a chave de cache usada numa correspondência futura. A RFC 9111 define a comparação, incluindo normalização e ausência. Um Vary contendo * nunca corresponde. Em vez de unificar esperas, Vary fornece evidência para distingui-las.

Authorization torna o limite concreto. Pela RFC 9111, um cache compartilhado não pode reutilizar uma resposta armazenada a uma requisição com Authorization em requisições posteriores, salvo quando uma diretiva Cache-Control habilita o uso e seus requisitos são cumpridos. Isso não faz de todo grupo um fluxo autenticado; mostra que a distribuição não pode ultrapassar as regras normais de reutilização.

Medir apenas “consultas à origem poupadas” é perigoso. O sucesso da requisição principal prova que uma transação obteve resposta. Não prova que cada requisição associada compartilhe campos de seleção, restrições de autorização, estado de frescor ou permissão de uso. Quando diferem, encaminhar separadamente é correção, não desperdício.

Um recibo de liberação do agrupamento preserva capacidade e evidência. Ele é uma síntese editorial de controle, não um objeto definido pelo IETF. O recibo liga a requisição principal a cada requisição em espera, registra resposta e objeto armazenado, normaliza método e alvo, compara Vary, avalia Authorization e Cache-Control e grava, para cada uma, liberação ou encaminhamento separado.

A distinção fica operacional: o agrupamento compartilha uma busca; a entrega da resposta continua sendo uma decisão individual. O operador mede trabalho evitado sem classificar uma distribuição indevida como acerto do cache.

Fontes