Resumen

  • 201 Created confirma que un CDN creó el recurso de activación; no confirma que haya terminado la purga, la invalidación o el preposicionamiento.
  • Si un CDN de tránsito ya aceptó la orden y otro CDN situado más abajo la rechaza, la revisión 20 obliga a transformar ese rechazo HTTP en un Error.v2 asíncrono dentro del recurso de estado intermedio.
  • El PID del CDN que originó el fallo puede omitirse. Los estados, recuentos, carreras de cancelación, nodos que regresan y resultado para el usuario deben auditarse por separado.

A aceptó; C rechazó

El ejemplo más útil no empieza con una caída, sino con una respuesta correcta. El CDN A envía a B una orden para eliminar contenido. B autentica la petición, crea un recurso y responde 201 Created. Después B delega en C. C detecta una acción o una especificación que no admite y responde 400 Bad Request.

La aceptación de B no queda anulada como hecho histórico. Demuestra que B creó un recurso. El rechazo de C tampoco es una contradicción: demuestra que otro tramo no creó el suyo. El error aparece cuando el cuadro de mando convierte el primer hecho en prueba del resultado completo.

La revisión 20 de CDNI Control Interface / Triggers 2nd Edition, fechada el 2 de septiembre de 2026, explica cómo conservar esta diferencia. El registro de Datatracker la presenta como un Internet-Draft activo del grupo CDNI, en estado WG Document. El texto sustituiría a RFC 8007 si se aprobara. Todavía no es RFC, aprobación del IESG, prueba de producto ni prueba de despliegue.

Frente a la revisión 19, la versión nueva amplía de manera sustancial el tratamiento de errores y su propagación. El hecho noticioso no es que exista una orden purge. Es que un rechazo directo cambia de naturaleza después de que otra frontera administrativa ya dijo que sí.

El protocolo no puede reescribir una respuesta pasada

Cuando B descubre un defecto antes de aceptar —formato incorrecto, falta de permiso o elemento no soportado localmente— devuelve 4xx y no crea recurso. Si B ya respondió a A, el intercambio HTTP de creación terminó. El 4xx o 5xx posterior de C no puede reaparecer como la respuesta que A recibió en el pasado.

Por eso B debe convertirlo en una Error.v2 Description y añadirlo al arreglo de errores de su propio recurso. También debe propagar los fallos asíncronos que C comunique después de aceptar. A los descubre al consultar el estado, posiblemente como failed con eunsupported.

La traducción conserva el problema, pero añade un testigo. C afirmó el rechazo ante B; B lo afirma después ante A. Guardar sólo el 201 destruye la segunda parte. Guardar sólo el Error.v2 sin el historial de transformación destruye la procedencia.

Además, B puede incluir el CDN Provider ID de C, pero no está obligado. Puede poner su propio PID y ocultar qué proveedor descendente falló. Los registros CDNI de IANA normalizan nombres y tipos; no imponen transparencia sobre una cadena comercial.

Un estado terminal tiene perímetro

El ciclo normal pasa de pending a active y termina en complete o failed. Un CDN de tránsito no puede declarar complete hasta que el trabajo haya terminado tanto en él como en todos sus CDN descendentes. Si alguna parte entra en processed, el tránsito debe reflejar processed.

Ese estado indica una limitación deliberada: el CDN aceptó el trabajo, pero ya no ofrecerá nuevas actualizaciones. No es un sinónimo de completo. La recomendación de usar identificadores únicos según RFC 9562 protege la identidad del recurso, no autentica el efecto de la orden.

Cuando una rama falla, el tránsito espera a que termine el procesamiento en todas las ramas antes de publicar failed. El terminal pertenece al grafo que el protocolo conoce. No señala la hora del primer fallo ni la recuperación visible para una audiencia.

El contador no promete objetos únicos

La revisión 20 incorpora totales acumulados de objetos, nodos y bytes. Recomienda sumar el trabajo de nodos locales y CDN en cascada sin eliminar duplicados cuando el mismo objeto se procesa en varios nodos. Sirven para detectar resultados anormalmente altos o bajos.

Por tanto, 10.000 operaciones no equivalen necesariamente a 10.000 objetos distintos. Y cero objetos puede coexistir con éxito: una purga que no coincide con contenido conocido no debe tratarse como error. El contador mide actividad bajo una definición; no es un censo ni una observación del cliente final.

Cancelar compite con ejecutar

La implementación real de la cancelación es opcional. Aunque B acepte cancelarla, el estado pending que A leyó puede haber cambiado antes de procesar la petición. Un trabajo active o processed puede terminar durante la carrera. Cancelling comunica intención y progreso, no ausencia instantánea de efectos.

Borrar el recurso tampoco es una cancelación más fuerte. La eliminación retira la superficie de estado y provoca 404 Not Found en consultas posteriores. El proyecto aconseja cancelar, no borrar, cuando A necesita conocer el estado terminal. Un 204 No Content se refiere al recurso de seguimiento.

La frontera temporal del contenido añade otra dificultad. Purge e invalidate deben aplicarse a datos adquiridos antes de entrar en active y deberían alcanzar adquisiciones que ya están en curso. No deberían alcanzar datos adquiridos después, pero A no debe confiar en que esa exclusión sea siempre viable. Si una nueva versión se preposiciona sin ordenar primero el fin de la purga, la propia sustitución puede ser eliminada.

La arquitectura completa viene de RFC 6707, el marco de interfaces de RFC 7336 y los requisitos de control de RFC 7337. RFC 9110 aporta la semántica HTTP. Juntas no convierten un éxito de creación en garantía sobre una operación distribuida posterior.

El nodo que vuelve no estaba en la foto

La ausencia temporal de un nodo descendente debe gestionarse internamente y no tendría que cambiar por sí sola el estado comunicado. Antes de regresar al servicio normal, el nodo debería reconciliarse con las operaciones ejecutadas durante su ausencia.

Esa abstracción oculta complejidad legítimamente, pero desplaza la confianza. El estado que vio A no fue una observación directa del nodo ausente. Una prueba por la ruta del usuario después de su regreso mide algo diferente y necesario.

Las topologías en diamante pueden entregar metadatos contradictorios por rutas con retardos distintos y se consideran error de configuración. La ruta de PID ayuda a detectar bucles, pero la atribución de errores sigue siendo opcional.

CDNI mejora la cadena de constancias. No declara que una sola constancia sea todo el resultado.