Resumen

  • draft-ietf-httpbis-pre-denied-01 propone 419 para indicar que el servidor rechazó la petición asociada por su propósito declarado; no convierte ese evento en una regla para la siguiente petición, aunque lleve el mismo propósito.
  • El estado no sería almacenable de forma heurística y no debería guardarse. Antes de contar rechazos repetidos, la operación debe probar si hubo decisiones nuevas o la reproducción de una respuesta antigua.

La primera petición especulativa llegó al origen y fue rechazada. Las siguientes cien no llegaron. Un caché había conservado la respuesta y la sirvió como si expresara una propiedad estable del recurso. El cuadro de mando mostró cien decisiones de política; el servidor había tomado una.

El error no estaba en el código propuesto. Estaba en borrar la relación entre la respuesta y su petición asociada. Una clasificación precisa pierde toda precisión cuando la infraestructura la separa de su tiempo, su propósito y su productor.

La revisión 01 de The Purpose Declined HTTP Status Code es un Internet-Draft activo del grupo HTTP de la IETF, publicado el 9 de septiembre de 2026 y con vencimiento el 13 de marzo de 2027. Aspira a la vía de estándares, pero continúa siendo trabajo en curso. En el momento de congelar las fuentes, IANA no había asignado 419 en el registro de códigos HTTP. No es correcto presentarlo como RFC, código permanente, práctica desplegada ni evidencia de interoperabilidad.

El problema que intenta nombrar

El estándar Fetch permite que el agente de usuario declare un propósito mediante Sec-Purpose. El caso motivador es la obtención especulativa: el navegador solicita una representación antes de una navegación ordinaria para intentar reducir la espera posterior. El servidor puede concluir que responder no ayudará y que incluso tendrá efectos negativos.

Usar 503 para ese rechazo induce otra lectura. RFC 9110 relaciona 503 con incapacidad temporal por sobrecarga o mantenimiento. El operador que ve un aumento puede abrir un incidente de capacidad aunque el servidor esté funcionando exactamente como fue configurado.

El 419 propuesto daría nombre a la diferencia: la petición fue rechazada por su propósito declarado. No crea una facultad nueva. Tampoco demuestra que la política sea correcta, que el propósito refleje la intención de una persona o que la aplicación de origen haya participado.

Esa modestia es su utilidad. Una señal operativa mejora cuando dice menos con mayor precisión.

Una petición no es el futuro del recurso

El borrador declara que la indicación solo se aplica a la petición asociada. Otra petición con el mismo propósito puede tener éxito o no. La frase excluye una inferencia frecuente: convertir el evento en prefetch_bloqueado=true para siempre.

La carga puede cambiar, el caché puede llenarse, la representación puede ser más barata, una regla de borde puede modificarse o la nueva solicitud puede entrar por otro camino delegado. También puede fracasar por autenticación, autorización o disponibilidad sin relación con el propósito.

El registro seguro es un hecho fechado: actor, petición, propósito recibido, política, respuesta y contexto. Una política duradera requiere una fuente duradera, como una configuración autenticada y versionada. El resultado de ayer no debe ocupar el lugar de la decisión de hoy.

Esta separación permite automatizar sin inventar. El cliente puede reducir reintentos especulativos durante un intervalo local, aplicar dispersión o probar de forma limitada. No debe declarar inaccesible la representación ni asumir que la navegación normal recibirá el mismo trato.

El caché puede multiplicar una autoridad que no posee

El proyecto señala que la respuesta no es heurísticamente almacenable y que no debería almacenarse. RFC 9111 define las reglas generales de almacenamiento y frescura. La razón específica aquí es más profunda que ahorrar ancho de banda: la decisión se refiere a una solicitud y no debe migrar a otra por comodidad.

Si un intermediario reutiliza el rechazo, deja de limitarse a transportar una decisión. Empieza a decidir qué futuras peticiones quedan sujetas a ella. Esa ampliación de alcance requiere autoridad y semántica que el 419 no concede.

Cache-Status, definido por RFC 9211, puede mostrar si un caché atendió, revalidó o reenvió. Es una pieza de procedencia, no una explicación completa. El código indica la clasificación presentada; Cache-Status describe el comportamiento del caché; los registros del decisor muestran si una evaluación ocurrió. La investigación necesita las tres capas.

Los contadores también deben distinguir respuesta original, reproducción y nueva evaluación. Sin ese control, una sola decisión puede parecer una ola de política y desencadenar cambios innecesarios.

La identidad del generador cambia la conclusión

El borrador permite que el origen o una pasarela que actúa en su nombre produzca el estado. Una CDN o un proxy inverso autorizado puede decidir sin consultar la aplicación. Un proxy que no actúa para el origen no debería hacerlo.

Por eso status=419 no basta para afirmar “el origen rechazó”. Puede probar que el cliente recibió la clasificación, mientras el punto exacto permanece incierto. La terminación TLS, la ruta, Via, Proxy-Status, identificadores correlacionados y registros de la pasarela ayudan a ubicarla.

Tampoco hay que caer en el extremo contrario. Una decisión de una pasarela delegada puede ser una decisión real de control para el origen. Llamarla ruido del proxy borra autoridad legítima. La conclusión correcta nombra al actor demostrado y no le atribuye la salud ni la intención de otros componentes.

Propósito declarado no equivale a identidad ni consentimiento

Sec-Purpose comunica contexto de la solicitud. Un agente puede marcar prefetch por una heurística propia. Ese valor no autentica al usuario, no demuestra un clic futuro y no autoriza una operación de negocio.

Aceptar el prefetch tampoco completa nada. La navegación puede no ocurrir. Rechazarlo no niega acceso al usuario. Una solicitud normal puede seguir y recibir la representación. Identidad, autorización, ejecución y resultado necesitan recibos independientes.

Esta frontera evita que la seguridad convierta un indicador técnico en juicio sobre una persona. También evita que producto mida como conversión un trabajo especulativo aceptado. El propósito orienta una decisión de recursos; no se convierte por sí solo en mandato.

Reclasificar no mejora automáticamente el servicio

Separar 419 de 503 puede limpiar los datos de incidentes. Sin embargo, una disminución de 503 después del cambio puede ser puramente contable. La capacidad no aumentó solo porque el rechazo recibió otro nombre.

Hay que medir disponibilidad de servicio, tasa de rechazo por propósito y resultado de la navegación posterior por separado. Si 419 desaparece de los objetivos operativos, una política excesiva puede aumentar la latencia de usuarios sin activar ninguna revisión. Si se suma a la indisponibilidad, vuelve a contaminar 503.

El indicador profesional no es “menos errores”. Es una matriz: qué propósito se declaró, quién tomó la decisión, si se reutilizó, qué ocurrió con la petición ordinaria y cuál fue el resultado visible. La semántica útil exige un modelo útil.

El cuerpo no debe gobernar la automatización

Las respuestas propuestas no están destinadas a mostrarse. Deberían tener contenido de longitud cero, y cualquier contenido enviado debería descartarse. Un texto explicativo puede provenir de una plantilla genérica y mencionar sobrecarga, permiso o plazo sin relación con la decisión.

La automatización que analiza ese texto crea un contrato privado no definido por el borrador. El estado sostiene una afirmación limitada; los detalles adicionales necesitarían un formato estable y procedencia propia.

El borrador también advierte que la emisión podría filtrar estado interno. Si el rechazo varía según capacidad, experimentos o calor del caché, un observador puede inferir transiciones. La organización debe decidir qué clasificación necesita exponer y qué información debe permanecer agregada.

Fuentes y límites

El paquete congelado conserva la revisión 01, sus registros de estado, historia y referencias, la página del grupo HTTP, el estándar Fetch, RFC 9110 y 9111, Proxy-Status, Cache-Status, BCP 14 y el registro IANA. Demuestra texto y estado documental, no adopción ni conducta real.

El ejemplo del caché es una situación analítica. No afirma un incidente, proveedor, producto o despliegue. El borrador puede cambiar o no llegar a RFC; el número puede no ser asignado en esta forma.

Fuentes