Resumo

  • draft-ietf-httpapi-ratelimit-headers-11 define unidades distintas para requisições, bytes de conteúdo e requisições concorrentes; o número só é interpretável junto da política, unidade, partição e momento da observação.
  • Uma quota positiva ajuda o cliente a modular o envio, mas não reserva CPU, fila ou resultado. O serviço pode alterar valores, recusar com r>0 ou atender com r=0, e a aplicação ainda decide autorização, validação e commit.

O conector recebeu r=300;t=60 para uma política medida em requisições. A fila tinha trezentos trabalhos: alguns consultas leves, outros relatórios que mantinham conexões, processadores e bancos ocupados por minutos. O orquestrador liberou todos porque “havia trezentas unidades”.

O contador HTTP permaneceu coerente. A concorrência colapsou primeiro.

O erro não foi aritmético. O sistema havia trocado a unidade declarada — requisição — pela unidade que precisava governar — trabalho simultâneo e custo de execução.

A revisão 11 de RateLimit header fields for HTTP foi publicada em 23 de maio de 2026 pelo grupo IETF HTTPAPI. É um Internet-Draft ativo, destinado ao Standards Track e com expiração em 24 de novembro de 2026. Não é RFC, prova de adoção ou relato de um serviço real. Seu texto, porém, permite analisar com precisão o que uma quota mede e o que ela não concede.

Antes do número vem a unidade

RateLimit-Policy descreve uma política nomeada. q informa a quota alocada; qu pode informar a unidade; w, a janela; pk, a partição. A revisão 11 começa com três unidades: requests, content-bytes e concurrent-requests.

Elas não são intercambiáveis. Cem requisições podem representar cem leituras baratas ou cem tarefas longas. Um limite de bytes não informa quantos objetos existem. Uma quota de concorrência mede ocupação simultânea, não necessariamente taxa de chegada. Mesmo em requests, o documento deixa para a implementação decidir se uma requisição específica consome uma unidade.

RateLimit comunica o limite corrente da política. r é a quota disponível, e t é a janela efetiva. Salvar apenas remaining=300 remove justamente a informação que permite controlar: trezentas de quê, em qual partição, segundo qual política e observadas quando?

Um registro útil conserva origem, horário, política, unidade, partição, q, w, r, t, status e características da requisição. Só então o cliente pode relacionar o sinal à fila correta.

A política mais próxima não é a única política

Mais de uma política pode limitar a mesma chamada. Um serviço pode impor quota diária, horária e de concorrência, mas anunciar apenas a que está mais perto de esgotar. A omissão das outras não prova que foram removidas.

Isso impede que o cliente reconstrua toda a função de admissão a partir de um item. Uma tarefa aparentemente dentro da quota horária pode atingir a diária. Uma chamada pequena em bytes pode ocupar a última vaga concorrente. Uma política não anunciada pode mudar antes da próxima resposta.

O cliente pode usar o item disponível para reduzir pressão. Não deve declarar que todas as demais restrições foram satisfeitas. O campo informa uma superfície; não audita as superfícies ausentes.

Quota disponível não é trabalho concedido

O rascunho afirma que r positivo não garante que novas requisições serão atendidas. A seção de segurança chama as unidades de dicas, não requisições concedidas nem acordo de nível de serviço.

Entre a resposta e o próximo envio, o serviço pode saturar, reduzir os valores em defesa, encontrar outra política limitante ou mudar a partição. A requisição pode falhar autenticação, autorização, esquema ou regra de negócio. Nenhuma dessas decisões é substituída pelo contador.

O inverso também vale. r=0 não obriga recusa. O serviço continua livre para atender, e a especificação não exige correlação entre campo e status. A discricionariedade pertence ao componente que executa a política.

Por isso, uma fila precisa de estados separados: elegível segundo a última observação; selecionada dentro dos limites locais; enviada; admitida; executada; confirmada. A quota só sustenta parcialmente os dois primeiros.

A janela efetiva não promete reposição

t limita quanto o cliente deveria consumir durante um intervalo relativo. A duração em segundos evita depender de relógios sincronizados e reduz o efeito de muitos clientes despertarem em um timestamp absoluto.

O fim do intervalo não recarrega automaticamente a quota. O documento proíbe presumir restauração total. Em janelas deslizantes, saturação ou controle adaptativo, o serviço pode alterar r e t, inclusive aumentar a nova janela.

Um controlador seguro invalida a observação antiga, introduz jitter, faz uma sondagem pequena e ajusta gradualmente dentro de seus próprios tetos. Ele não libera a fila acumulada quando o relógio chega a zero.

Retry-After pode orientar uma nova tentativa, mas também não reserva capacidade. Momento de tentar, janela de quota, admissão e conclusão são quatro fatos.

A partição é contabilidade, não autorização

pk identifica a partição de quota associada à requisição. Ela pode ser derivada de usuário, aplicação, método, recurso ou combinação. Uma regra documentada ajuda a prever se duas chamadas usam o mesmo saldo.

Mas a chave não autentica ninguém. Vários usuários podem compartilhar uma partição; uma pessoa pode atravessar várias; a regra pode mudar. O texto recomenda evitar dados sensíveis e considerar risco de personificação quando houver informação identificadora.

Autorização está explicitamente fora do escopo. Uma chamada dentro da quota pode ser proibida. Uma chamada autorizada pode estar sem quota. Até 401 e 403 podem consumir unidades dependendo do serviço. Usar o saldo como permissão cria uma passagem que a especificação não oferece.

O recibo de identidade, a decisão de acesso, a partição, a admissão e o resultado precisam ficar relacionados, mas independentes.

O proxy altera a conta sem aparecer na fila

Intermediários podem repetir uma requisição sem avisar o cliente. Duas tentativas podem consumir duas unidades embora a fila de negócio contenha um único item. Também podem impor uma política mais restritiva quando entendem a unidade e a aplicam de fato.

Um intermediário externo não deveria tornar a política do origin mais permissiva. E, mesmo presumindo que a chamada não será servida, normalmente deveria encaminhá-la. O serviço que retornou os campos continua responsável pela aplicação e livre para atender.

A divergência entre “itens enviados” e “unidades consumidas” exige linhagem: ID da requisição, ID da tentativa, salto, motivo do retry, resposta e política. Sem isso, o operador confunde comportamento da rede com abuso do consumidor.

Um valor grande pode acelerar a exaustão

O rascunho mostra que r alto com t curto pode induzir um cliente a usar r/t como taxa, muito acima da média indicada por q/w. Uma dica criada para evitar throttling vira sinal de aceleração.

O valor extremo pode ser erro, manipulação por intermediário ou folga real. Em qualquer caso, o cliente responde com seus próprios limites: taxa, concorrência, memória, custo e pressão a jusante. Ele sobe em rampa, aplica jitter, rejeita outliers e mantém circuit breakers.

Esse princípio é especialmente importante quando a quota usa requests e o risco usa outra unidade. O cliente precisa converter trabalho em orçamento local com uma regra própria e observável. Não pode fingir que o servidor já fez essa conversão.

O status e o problema não concluem a causa

A revisão 11 propõe tipos de problema para quota excedida, excedida temporariamente e uso anormal detectado. Eles podem listar políticas violadas e permitir ações diferentes.

“Uso anormal” continua sendo classificação do serviço, não prova independente de malícia ou identidade. Pode justificar reduzir a taxa, pausar o lote e abrir revisão. Não basta para banimento permanente ou acusação pública.

RFC 9457 define o contêiner, RFC 6585 o 429, RFC 9110 a semântica HTTP, e RFC 9651 a estrutura de listas e parâmetros. Sintaxe correta torna a afirmação legível; não transforma classificação em fato externo.

Fontes e limites

O pacote congelado reúne a revisão 11, estado, histórico e referências no Datatracker, escopo e trabalho de privacidade do HTTPAPI, RFCs 9110, 9651, 6585, 9457 e 9205, e registros IANA. Ele comprova texto e limites da proposta, não implementação, incidente, fornecedor, adoção, desempenho ou interoperabilidade.

Fontes