Resumen

  • Los bindings de WebDAV permiten que varias URI conduzcan al mismo recurso. Si el destino es una colección, un segundo binding vuelve accesibles los mismos miembros bajo otra ruta y puede crear un ciclo.
  • En un PROPFIND Depth: infinity de un cliente que comprende bindings, una aparición recibe 200 y despliega los descendientes. Las rutas posteriores siguen presentes con 208 Already Reported, pero no vuelven a enumerar ese subárbol.
  • DAV:resource-id separa la identidad estable del recurso de las rutas variables. El cliente debe conservar cada binding y expandir una sola vez cada colección; si no entiende 208, un bucle debe terminar con 508 en vez de producir una estructura parcialmente omitida que parezca completa.

El catálogo tenía dos fichas y una sola colección

Una misma caja de archivo puede figurar en dos secciones de un catálogo. Cada ficha importa: indica desde qué colección se accede, con qué nombre y bajo qué contexto. Pero ninguna ficha crea otra caja.

Un inventario que confunde dirección con objeto contará dos veces todo lo que hay dentro. Uno que elimina de inmediato la segunda ficha evitará el duplicado a costa de borrar una relación real. Y si una ruta conduce de nuevo a una colección antecesora, el primer algoritmo podrá recorrer para siempre una estructura finita.

208 introdujo un resultado más preciso. El servidor conserva la ficha posterior, demuestra que apunta a una colección ya desplegada y omite solamente otra copia de sus descendientes.

La finitud no se compra sacrificando la topología.

WebDAV ya exigía leer el detalle dentro de 207

El RFC 4918 de 2007 define el estado de una colección mediante mappings entre segmentos de ruta y recursos, además de las propiedades de la propia colección. El nombre del miembro forma parte del acceso; no es el objeto.

PROPFIND admite profundidad cero, uno o infinity. Una consulta infinita pide la colección y todos sus descendientes. La respuesta general es 207 Multi-Status, con una lista plana de elementos DAV:response. Cada href identifica una ruta y los propstat contienen estados para las propiedades solicitadas.

El 207 exterior nunca fue un veredicto único sobre todo el cuerpo. El cliente debe examinar los estados interiores. Esa arquitectura hace posible que 208 describa una ocurrencia concreta sin fingir que toda la petición fue “ya reportada”.

La especificación base reconocía que un recurso podía tener varias URI. La extensión posterior añadió el método con el que un cliente podía crear deliberadamente otra ruta hacia el recurso existente.

BIND creaba acceso compartido, no clonación

El RFC 5842, publicado como Experimental en abril de 2010, define BIND, UNBIND y REBIND. BIND relaciona un segmento de una colección con un recurso ya existente. La URI resultante sirve para enviar métodos a ese mismo recurso.

La nueva entidad de estado es el binding. El recurso no vuelve a nacer. Dos colecciones pueden contener bindings distintos hacia el mismo destino, incluso si usan el mismo nombre de segmento.

La integridad del binding obliga al servidor a mantener la relación y la identidad del destino hasta que una operación definida la quite o la cambie. Eliminar un binding no puede romper otro ni justificar la reclamación del recurso mientras quede otra vía.

Así se evita que una operación sobre un nombre adquiera por accidente autoridad sobre todos los demás nombres del objeto.

Enlazar una colección multiplicaba sus rutas descendentes

Un binding a un recurso hoja añade otra URI. Un binding a una colección también hace que sus miembros sean alcanzables bajo un nuevo prefijo, aunque las relaciones internas de los hijos sigan siendo estado de la única colección.

La consecuencia es que el número de mappings puede crecer sin que crezca el número de recursos. Si una colección se enlaza consigo misma o con un antepasado, una secuencia de URI puede repetir el mismo segmento sin fin.

RFC 5842 exige detectar esos ciclos al procesar Depth: infinity. El servidor puede negarse a crear el ciclo porque admitir bucles es opcional. Si lo admite, debe recorrer un grafo y no una jerarquía simple.

La amenaza de infinitud procede de expandir una identidad una y otra vez, no de que el almacenamiento contenga objetos infinitos.

El resource-id probaba qué había detrás del nombre

Las URI distintas no bastan para distinguir recursos, pues los aliases existen precisamente para ofrecer varios caminos. La igualdad de contenido tampoco sirve: dos recursos independientes pueden ser idénticos hoy y divergir mañana.

RFC 5842 exige DAV:resource-id, asignado al crear el recurso y único para todos los recursos a perpetuidad. No cambia cuando se actualiza el objeto existente o se hace REBIND, y no puede reutilizarse aunque ninguna URI siga alcanzándolo.

Dos valores iguales carácter por carácter obtenidos por rutas distintas demuestran que ambos bindings llegan a un solo recurso. El identificador no elige una URI principal; permanece por debajo de ellas.

El cliente puede pedir esta propiedad en PROPFIND y reconstruir la estructura: qué aristas son distintas, qué nodo comparten y por qué los descendientes omitidos en una ruta no están perdidos.

Un recorrido fiel llevaba dos inventarios

El inventario de aristas conserva cada binding y su href. El inventario de expansiones registra qué identidades de colección ya tuvieron sus miembros enumerados en esta respuesta.

Si el algoritmo usa solo las URI, conserva las aristas pero repite trabajo y no detiene ciclos. Si usa solo los resource-id y fusiona antes de registrar el binding, termina con una lista de objetos sin la topología que los hace accesibles.

La operación correcta registra primero la ruta. Después consulta si el nodo de destino ya fue desplegado. La deduplicación se aplica al trabajo de descenso, no a la relación del espacio de nombres.

208 es el enlace explícito entre ambos inventarios: esta arista existe; el subárbol asociado ya apareció en otro lugar del mismo resultado.

La segunda respuesta seguía allí

La semántica exacta limita 208 a Depth: infinity y a su uso dentro de DAV:propstat. Para los bindings que llevan a una misma colección dentro del alcance, una aparición se informa con 200 y despliega los descendientes. Las siguientes conservan un elemento DAV:response con 208 y no incluyen respuestas nuevas para esos descendientes.

No se omite el alias. Su href permanece y su resource-id permite enlazarlo con el 200 anterior.

En el ejemplo normativo, /Coll/ y /Coll/Bar tienen el mismo identificador. El primero recibe 200 y lista los miembros; el segundo recibe 208. La recursión no continúa por /Coll/Bar/Bar, porque volvería al mismo nodo.

Already Reported describe la historia de enumeración de este cuerpo. No dice que la URI sea redundante en el sistema.

El primer camino no obtenía privilegio canónico

El servidor debe escoger una aparición para desplegar los hijos. Esa elección distribuye el coste de una respuesta; no designa un dueño del recurso.

El binding con 200 no se vuelve automáticamente original, preferente ni permanente. Los bindings con 208 siguen perteneciendo al estado de sus respectivas colecciones y pueden tener distinto contexto de navegación, autorización o auditoría.

Un cliente que borra esas rutas convierte una optimización temporal en una decisión estructural. Puede confundir UNBIND con eliminación del recurso o atribuir a una colección padre control sobre relaciones mantenidas por otra.

La primera visita no otorga soberanía sobre todas las puertas.

207 seguía siendo el contenedor

La línea de estado de la petición normalmente dice 207 Multi-Status. El 208 está dentro del detalle de propiedades correspondiente a una ruta.

El nivel exterior indica que el cuerpo contiene una cuenta plural. Los niveles interiores indican qué ruta se expandió y cuál remite a esa expansión. href preserva la identidad del camino; resource-id demuestra la identidad compartida del nodo.

Por eso 208 no significa que el cliente repitió una solicitud HTTP ni que toda la respuesta había sido enviada previamente. Afecta a la enumeración de una colección dentro de este Multi-Status.

Si un proxy, biblioteca o adaptador reduce el XML a success=true, mantiene el número 207 pero destruye la evidencia necesaria para reconstruir el grafo.

La omisión dependía de una negociación

Un cliente antiguo podría ver una ruta con hijos ausentes y concluir que la colección está vacía. Para él, un estado interior desconocido no explica dónde se encuentran esos hijos.

El servidor que soporta bindings anuncia la clase bind en el encabezado DAV de OPTIONS. El cliente debería enviar DAV: bind; al hacerlo, debe comprender 208.

La especificación recomienda no usar 208 dentro de Multi-Status cuando el cliente no ha señalado esa capacidad. La compatibilidad no consiste en enviar menos y esperar que el receptor adivine.

La supresión de descendientes es segura porque ambas partes comparten resource-id, semántica de binding y significado del estado. Sin ese acuerdo, el ahorro se vuelve ambigüedad.

508 señalaba que el recorrido no podía continuar

Si un cliente no consciente de bindings provoca una condición de bucle en un PROPFIND profundo, la respuesta compatible es 508 Loop Detected. Puede ser un estado superior si el servidor descubre el ciclo antes de empezar a transmitir, o aparecer en el Multi-Status cuando el hallazgo llega durante el streaming.

208 y 508 no son dos intensidades del mismo mensaje. Con 208, el servidor continúa y entrega una descripción finita: conserva el alias y evita repetir el subárbol. Con 508, termina la operación al encontrar un bucle infinito y declara el fracaso.

El cliente preparado puede reconstruir una referencia. El no preparado necesita un límite visible. Una interrupción explícita es preferible a una respuesta parcial que parezca una jerarquía completa.

Los aliases también ampliaban la superficie de ataque

BIND abre una vía para crear ciclos por error o con intención hostil. La detección durante Depth: infinity es obligatoria, pero no agota la seguridad del grafo.

RFC 5842 advierte sobre privacidad y denegación de servicio. Los bindings entre servidores pueden dirigir uso hacia destinos no dimensionados para ello. La propiedad opcional DAV:parent-set puede revelar ubicaciones privadas y forzar el mantenimiento de listas de bindings influenciadas por otros dominios administrativos.

208 reduce la repetición en una sola respuesta. No fija límites de CPU, memoria, nodos o tamaño, ni decide quién puede crear una arista. Un grafo finito todavía puede ser demasiado grande; una ruta legítima todavía puede revelar información sensible.

El estado resuelve un mecanismo de amplificación sin reclamar control sobre todo el sistema.

La identidad compartida no borraba el contexto de ruta

El mismo resource-id no exige que toda propiedad observada por dos bindings sea idéntica. Los dead properties son independientes del número de bindings y del camino, pero cada live property conserva su propia definición y algunas observaciones pueden depender de la ruta.

Fusionarlo todo por identidad borra contexto. Separarlo todo por URI duplica el objeto. El modelo necesita tres planos: hechos del recurso, hechos del binding y observaciones ligadas al camino.

208 funciona porque respeta esos planos. Usa la identidad común solo para decidir si repetir un descenso; no la convierte en permiso para borrar la pluralidad del espacio de nombres.

La coordinación mínima es más robusta cuando su autoridad coincide con lo que la evidencia demuestra.

IANA conservó el alcance estrecho

El registro de códigos de estado HTTP de IANA apunta 208 Already Reported a RFC 5842. El mismo RFC Experimental define 508; 207 sigue vinculado al WebDAV de RFC 4918.

El registro no convierte el experimento en Internet Standard, no demuestra adopción actual y no autoriza a reutilizar 208 como marcador genérico de filas duplicadas, idempotencia o caché.

Su significado nace de un contexto concreto: PROPFIND con profundidad infinita, Multi-Status, bindings y un cliente que declaró comprenderlos.

Esa precisión impide que la palabra «already» se convierta en una excusa para descartar cualquier cosa repetida.

Cada arista, una sola expansión

HTTP 208 no eliminó el grafo para recuperar la comodidad de un árbol. Conservó los caminos, estabilizó la identidad y limitó el trabajo.

Cada binding aparece porque el acceso es parte de la realidad. Cada recurso conserva un identificador porque no pertenece a una sola URI. Los descendientes se enumeran una vez porque repetirlos no añade estructura. La omisión se marca porque, sin explicación, parecería pérdida de datos.

Ninguna ruta obtiene autoridad central. Ningún alias se convierte en copia. Ningún ciclo puede obligar a inventar una colección infinita.

La segunda ficha queda en el catálogo; la caja compartida no necesita otro inventario.