Resumen

  • Un borrador activo de HTTP propone 419 Purpose Declined cuando el servidor rechaza una petición por su Sec-Purpose. Es un recibo limitado a esa petición, no una prohibición permanente, un diagnóstico de salud ni una facultad nueva. El 29 de septiembre de 2026, IANA aún marcaba 419–420 como no asignados.
  • Hay que conservar propósito, decisor autorizado, reglas de caché, tratamiento del cliente, población del SLO y demanda real posterior. Si un SDK o panel reduce 419 a «otro 4xx», la red tiene una etiqueta nueva pero la organización mantiene la misma historia falsa.

Una precarga llega antes que la necesidad. El cliente calcula que el usuario quizá visite una ruta y pide la representación por adelantado. Si acierta, reduce espera. Si falla, el origen ha pagado cómputo, lectura y transferencia para un recurso que nadie usó. La decisión de admitir esa apuesta no es idéntica a la capacidad de servir una visita real.

Los sistemas de métricas suelen olvidar esa diferencia. Un origen puede estar estable, con dependencias y peticiones inmediatas sanas, y aun así devolver 503 Service Unavailable para no ejecutar ciertas precargas. El panel suma los 503, consume presupuesto de error y despierta a guardia. La política funcionó; la clasificación la presentó como avería.

draft-ietf-httpbis-pre-denied-01, del 9 de septiembre de 2026, propone 419 Purpose Declined: el servidor rehúsa esta petición por el propósito que declara. Es un Internet-Draft del grupo HTTP con intención de Standards Track, no un RFC. IANA mantenía 419–420 sin asignar al congelar la investigación.

La propuesta no autoriza algo nuevo. El servidor ya puede rechazar. Permite nombrar la diferencia entre «no puedo servir» y «no acepto esta finalidad especulativa ahora». Esa separación cambia qué equipo investiga, qué contrato se mide y quién debe explicar la decisión.

El encabezado aporta contexto, no certeza

Fetch define Sec-Purpose para peticiones destinadas a algo distinto del uso inmediato por una persona. Su único token definido es prefetch: obtener un recurso que se anticipa necesario pronto. Cuando el iniciador es una precarga, el algoritmo establece Sec-Purpose: prefetch.

El servidor puede variar caducidad de caché, impedir la precarga o contarla de forma distinta a una visita. No obstante, el encabezado no demuestra que habrá navegación, que la predicción sea buena, quién es el usuario ni que la descarga produzca valor.

El cliente declara una razón; el origen decide admisión. Una pasarela puede hacerlo si actúa por el origen. Un intermediario cualquiera no adquiere autoridad por observar el tráfico. Mantener esa frontera evita convertir una pista útil en mandato.

La especificación mínima necesita solo dos piezas comunes: propósito declarado y rechazo acotado. Precios, carga, contratos y umbrales continúan como decisiones locales de quienes soportan el coste.

503 y 403 cuentan historias demasiado grandes

RFC 9110 reserva 5xx para un servidor que no logra cumplir una petición aparentemente válida. Investigar capacidad o dependencias ante un pico de 503 es correcto. Si el mismo código incluye el rechazo deliberado de trabajo opcional, esa reacción correcta se dirige al lugar equivocado.

No es solo ruido. El error budget mezcla disponibilidad con aceptación especulativa. Un cliente recibe una tasa que no representa su servicio. Planificación puede comprar capacidad para reducir una curva causada por ahorro intencional. Los incentivos premian servir apuestas inútiles para que el panel permanezca verde.

403 Forbidden tampoco expresa bien el alcance. Parece negar el recurso, cuando una petición inmediata puede funcionar segundos después y la siguiente precarga puede admitirse. 419 dice algo menor y más exacto: esta petición fue rechazada por su propósito.

La decisión no debe sobrevivir a la petición

El borrador limita la indicación a la petición asociada. Peticiones futuras con el mismo propósito pueden tener otro resultado. El rechazo de las 09:17 no es una propiedad del URL a las 09:18.

Por eso 419 no es heurísticamente cacheable y el texto aconseja que no sea cacheable. Reutilizarlo trasladaría la decisión desde el origen y su estado presente hacia un caché que conserva un juicio antiguo. Si una visita inmediata recibe ese rechazo almacenado, una optimización ha creado una caída auténtica.

La respuesta no está destinada a mostrar contenido: debería tener longitud cero y cualquier contenido debería descartarse. El sentido operativo vive en la cabecera, la regla y el trace, no en una página de error que una precarga no enseña.

La prueba adecuada envía precargas repetidas con cambio de condiciones y luego una petición inmediata. Comprueba que no hay reutilización, que cada solicitud llega al decisor correcto y que una respuesta vacía no aparece en la interfaz.

El decisor necesita mandato

Pueden emitir 419 el origen y las pasarelas que actúan en su nombre, como CDN o proxies inversos. Otros proxies no deberían. Esta regla impide que un intermediario ajeno suprima la petición y atribuya falsamente la decisión al servicio.

El registro operativo debe identificar punto de emisión, relación de delegación, versión de política, regla y entradas. Sec-Purpose no autentica al remitente. La capacidad de un CDN para entregar objetos tampoco equivale a permiso ilimitado para cambiar semántica de admisión.

El borrador advierte que 419 podría filtrar estado interno. Si el patrón revela carga o umbrales, aparece un canal de sondeo. La respuesta es limitar detalle y abuso, no volver a un 503 que confunde realidades.

Compatibilidad de clase no es compatibilidad de significado

RFC 9110 exige que un cliente que desconoce un código comprenda la clase; un 4xx desconocido se maneja como un 400 genérico. Es un suelo seguro, pero pierde la explicación.

Un SDK puede nombrarlo bad request; un almacén, other_4xx; una librería de reintentos, error del cliente; un panel, fallo rojo. Todo sigue ejecutándose y, sin embargo, la distinción se pierde. Running-Code Primacy obliga a comprobar cliente, borde, origen, caché, tracing, métricas, alertas, SLO y reporte.

Hay que mantener tres ejes: propósito especulativo, identidad del decisor y resultado de la petición inmediata posterior. Muchos 419 pueden reflejar un nuevo cliente agresivo sin caída. Pero 419 no es siempre inocuo: una regla errónea, falsificada o demasiado amplia puede perjudicar.

Unir el código con la realidad posterior

El recibo completo incluye ID, método, objetivo, iniciador, Sec-Purpose, versión cliente y estado de caché; después, decisor, delegación, versión de política, regla y hora; luego, status, controles de caché, longitud y posición de trace. Finalmente se enlaza con la demanda real: éxito, latencia, bytes, trabajo del origen y resultado visible.

Si el usuario nunca pide el recurso, quizá se evitó trabajo, pero el ahorro debe medirse. Si lo pide y recibe respuesta normal, se demuestra salud del servicio aunque pueda haber coste de latencia. Si falla también, el 419 previo no borra el incidente. Si recibe un 419 cacheado, se violó el alcance.

La disponibilidad de demanda inmediata y la tasa de admisión de precarga necesitan SLO distintos. Pueden correlacionarse con coste y experiencia, nunca fundirse sin explicar el denominador.

Las fuentes demuestran el texto propuesto, su estado, el significado Fetch, las reglas HTTP y que IANA no había asignado 419. No demuestran navegador, CDN, despliegue, interoperabilidad, ahorro o adopción. Esos hechos requieren implementaciones, ensayos, traces y resultados.

La virtud del proyecto es su modestia: un nombre para una decisión existente, limitado a una petición, no cacheable, sin cuerpo visible y con emisor acotado. Solo cuando los sistemas reales conservan esas fronteras puede el panel distinguir una negativa intencional de una caída.

Fuentes