Resumen

  • draft-ietf-httpapi-ratelimit-headers-11 no exige correlación entre el valor de RateLimit y el código de estado: una respuesta exitosa puede anunciar r=0, y el servicio conserva la facultad de atender una petición posterior.
  • El código de la respuesta pasada, el límite observado, la decisión local de envío, la admisión posterior y el resultado de negocio son hechos distintos. Automatizarlos exige conservar cada recibo, no condensarlos en “disponible/no disponible”.

La primera llamada devolvió 200 OK. En la misma respuesta apareció RateLimit: "default";r=0;t=48. El conector vio el cero, clasificó el servicio como caído y retuvo una confirmación urgente durante cuarenta y ocho segundos.

Otro cliente envió su petición. El servidor la atendió.

Ninguna de las dos respuestas violó el borrador. La primera operación ya había tenido éxito. El cero comunicaba una política y una disponibilidad actuales, no una prohibición universal. El servicio seguía siendo el único que podía aplicar su límite y decidir si atendía la siguiente solicitud.

La revisión 11 de RateLimit header fields for HTTP fue publicada el 23 de mayo de 2026 por el grupo IETF HTTPAPI. Es un Internet-Draft activo, pensado para el Standards Track, y expira el 24 de noviembre de 2026. No es un RFC ni demuestra despliegue, adopción o interoperabilidad. Sí ofrece una gramática rigurosa para no confundir observación con decisión.

El estado mira hacia atrás; el límite orienta hacia delante

Un código 2xx expresa el resultado de la petición a la que pertenece. Un 429 indica que el cliente ha enviado demasiadas solicitudes según la política del servidor. Ninguno de los dos, por sí solo, describe toda la capacidad futura.

El borrador permite que RateLimit aparezca en respuestas satisfactorias, fallidas o limitadas. No fija una correlación obligatoria entre sus valores y el estado. De ahí que un 200 pueda llevar r=0: la operación terminó, pero la indicación aconseja no consumir más cuota en la ventana efectiva. También puede ocurrir que una petición posterior sea servida pese al cero, porque el servidor cambió de estado o ejerció su discreción.

El error operativo nace cuando la plataforma reduce dos tiempos a una bandera. “La API está disponible” extraído de 200 puede sobrevivir demasiado. “La API está cerrada” extraído de r=0 puede negar trabajo que el servicio habría aceptado. El registro correcto conserva respuesta anterior y observación de cuota como hechos relacionados, no idénticos.

La política necesita nombre, unidad y partición

RateLimit-Policy anuncia una política con un nombre y un cupo q. Puede añadir la unidad qu, la ventana w y la clave de partición pk. Las unidades iniciales son peticiones, bytes de contenido y peticiones concurrentes. Saber que el valor es cien no sirve si no sabemos si cuenta llamadas, volumen o simultaneidad.

RateLimit comunica el límite de servicio actual de una política concreta. r es la cuota disponible y t la ventana efectiva. Varias políticas pueden afectar la misma petición: una diaria, otra horaria, otra para concurrencia. El servidor puede mostrar solo la más próxima a agotarse.

Por eso un campo local llamado remaining es insuficiente. Debe existir una observación fechada con origen, política, unidad, partición, q, w, r, t y estado HTTP. Si una política no aparece, el cliente no puede concluir que dejó de actuar.

La estructura permite decisiones prudentes: reducir velocidad, aplazar trabajo no urgente o elegir otra cola. No permite reconstruir el algoritmo entero del servidor.

Cero no significa denegación, positivo no significa concesión

La especificación afirma que un valor positivo no garantiza que se sirvan nuevas peticiones. En su sección de seguridad recalca que las unidades disponibles son indicios, no peticiones concedidas ni un acuerdo de nivel de servicio.

El principio funciona en ambos sentidos. r=0 no obliga al servidor a rechazar. r=50 no obliga al servidor a aceptar cincuenta. Entre la observación y la siguiente llamada pueden cambiar la carga, una defensa contra abuso, otra política o la propia partición. Además, la solicitud puede carecer de permiso o fallar una validación ajena a la tasa.

Esta elasticidad no convierte el campo en inútil. Lo convierte en lo que declara ser: información para que un cliente cooperativo evite limitaciones previsibles. Un controlador puede bajar su ritmo con el cero sin afirmar que el servicio está caído. Puede aprovechar un valor positivo sin etiquetar el trabajo como admitido.

La admisión solo existe cuando la petición posterior recibe su respuesta. La ejecución requiere un recibo de la aplicación. El resultado para el usuario exige todavía otra evidencia.

La ventana efectiva tampoco decide el próximo estado

t señala cuántos segundos abarca el límite comunicado. Al usar una duración relativa evita depender de relojes sincronizados y reduce la estampida que produce una fecha de reset común.

No promete reposición. El texto prohíbe suponer que toda la cuota se restaurará al terminar. El servidor puede cambiar r y t entre respuestas, ampliar la ventana o reducir el valor por saturación. En un sistema de ventana deslizante no existe necesariamente un instante único de relleno.

Cuando vence t, la observación antigua caduca. El cliente puede hacer una prueba limitada, con espera aleatoria y límites propios. No debe rellenar su contador a q ni soltar todas las tareas acumuladas.

Retry-After puede acompañar una respuesta y orientar el momento de reintento. El borrador recomienda que no apunte antes del final de la ventana efectiva. Aun así, reintentar no equivale a tener plaza reservada. El siguiente estado vuelve a pertenecer al servidor.

La partición no autentica al actor

La clave pk ayuda a reconocer el depósito de cuota aplicable. Puede derivarse de usuario, aplicación, método, recurso o combinaciones. Si el algoritmo está documentado, el cliente puede estimar qué peticiones futuras compartirán asignación.

Esa correspondencia contable no prueba identidad. Un gateway puede agrupar muchos usuarios. Un usuario puede consumir varias particiones. La clave puede contener datos identificadores y ser susceptible de suplantación. El borrador pide evitar información sensible y utilizar solo elementos presentes en la petición para generarla.

La autorización queda fuera del alcance de los campos. Una solicitud bajo cuota puede estar prohibida. Una solicitud autorizada puede ser limitada. Incluso un 401 o 403 puede consumir cuota según la implementación. Mezclar estas decisiones produce diagnósticos falsos y rutas de evasión.

El historial debe unir, sin fusionar, la identidad autenticada, la decisión de autorización, la partición de cuota y la respuesta de aplicación.

El intermediario puede contar una petición que el cliente no vio

Los proxies introducen otra asimetría. Un intermediario puede reintentar una llamada de forma transparente y consumir unidades sin que el agente de usuario incremente su contador. También puede imponer una regla más restrictiva cuando entiende la unidad y hace cumplir su propia política.

No debería volver más permisiva la política del origen. Y, aunque presuma que la petición será rechazada, normalmente debería remitirla: el servicio que emitió la política conserva la responsabilidad de aplicarla y la libertad de servir.

Cuando el contador del cliente y el del servidor difieren, la explicación no está contenida en el número. Hacen falta identificadores de petición, intentos, saltos, respuestas y política aplicada. Sin esa cadena, acusar a un consumidor de exceder su asignación puede ser tan infundado como culpar al servidor de perderla.

Una señal permisiva también puede hacer daño

Un r grande y un t corto puede inducir a dividir ambos y disparar una tasa muy superior al promedio q/w de la política. El propio mecanismo de cooperación puede provocar agotamiento si el cliente lo trata como orden de aceleración.

El valor extremo puede ser legítimo, erróneo o manipulado por un intermediario. El cliente no necesita resolver primero esa intención para actuar con prudencia. Mantiene máximos locales de tasa, concurrencia, memoria y coste; aplica rampa; introduce jitter y rechaza valores fuera de su envolvente.

La automatización segura usa información remota para elegir dentro de límites propios. No conecta directamente un entero no reservado con un actuador sin freno.

El tipo de problema es una clasificación del servicio

La revisión 11 propone tipos para cupo excedido, agotamiento temporal y uso anormal detectado. Pueden incluir las políticas infringidas y mejorar las reacciones automáticas.

Pero “uso anormal” no demuestra malicia, persona o intención. Es la clasificación del servicio. Puede justificar pausar, reducir ritmo o pedir revisión. No basta para suspender irrevocablemente una cuenta o atribuir un ataque sin evidencia adicional.

RFC 9457 define el contenedor, RFC 6585 el estado 429, RFC 9110 la semántica HTTP y RFC 9651 la sintaxis estructurada. Un mensaje bien formado sigue siendo una afirmación con alcance y autor identificables.

Fuentes y límites

El paquete congelado reúne la revisión 11, su registro, historial y referencias Datatracker, el mandato HTTPAPI y su borrador de privacidad, RFC 9110, 9651, 6585, 9457 y 9205, y los registros IANA. Define el mecanismo propuesto y sus límites; no prueba implementación, incidente, proveedor, cuota real, rendimiento, adopción ni interoperabilidad.

Fuentes