Prompt y alcance
Los recursos de WebDAV pueden aparecer en múltiples rutas a través de vinculaciones (bindings). Por lo tanto, un recorrido recursivo de colecciones puede volver a visitar el mismo recurso o seguir un ciclo indefinidamente. La RFC 5842 define 208 Already Reported para miembros ya reportados en la misma respuesta multistatus y 508 Loop Detected cuando la operación se interrumpe tras encontrar un bucle.
Lo que el entrevistador está evaluando
- Si ubica el código 508 en su contexto de WebDAV en lugar de tratarlo como un error genérico de gateway.
- Si distingue 208 para un miembro ya reportado de 508 para una operación terminada.
- Si la profundidad, el recuento de nodos, el tiempo y los bytes de respuesta se convierten en presupuestos ejecutables.
- Si el comportamiento del cliente es idempotente, observable y está libre de reintentos infinitos.
Preguntas aclaratorias
- ¿El método es PROPFIND y Depth está configurado en infinity?
- ¿El recurso admite vinculaciones DAV y el cliente entiende 208?
- ¿El servidor debe devolver el árbol completo, un resultado acotado o solo una profundidad finita?
- ¿La colección abarca múltiples inquilinos (cross-tenant) y qué propiedades pueden divulgarse?
Respuesta en 30 segundos
Primero confirmaría un ciclo de vinculación de WebDAV en lugar de una redirección HTTP ordinaria. Durante el recorrido, rastrearía un ID de recurso estable y aplicaría presupuestos de profundidad, nodos, tiempo y bytes de respuesta. Si el cliente entiende 208, un miembro ya reportado puede representarse como tal; cuando el recorrido regresa a la pila de recursión activa y no puede completarse de manera segura, el servidor termina con 508 y un cuerpo de error estable. El cliente no debe reintentar a ciegas la misma solicitud de profundidad infinita; debe reducir la profundidad o solicitar que se repare la vinculación.
Respuesta en profundidad
1. Definir el límite del 508
508 significa que un servidor terminó una operación de WebDAV porque encontró un bucle mientras procesaba una semántica de profundidad infinita. No es un código genérico para discos llenos, tiempos de espera en upstream o cualquier falla recursiva. El cuerpo del error puede incluir un código estable y un ID de solicitud, pero no debe exponer las rutas ni la topología interna de otro inquilino.
2. Rastrear la identidad de la vinculación
Utilice el resource-id de DAV u otra identidad de recurso estable durante el recorrido en lugar de comparar únicamente la URL actual. Un recurso puede tener varias rutas, por lo que la deduplicación basada solo en URL omite alias; la identidad estable detecta miembros repetidos sin tratar un alias válido como un ciclo.
3. Elegir entre 208 o 508
Cuando la semántica del cliente y de la respuesta lo permitan, un miembro ya presente en el mismo resultado multistatus puede marcarse como 208 mientras otros miembros accesibles continúan. Si el recorrido regresa a un recurso en la pila de recursión activa y la operación no puede continuar de forma segura, deténgase y devuelva 508. Los significados son, respectivamente, "ya reportado" y "terminado debido a un bucle".
4. Aplicar presupuestos de recursos
Incluso un grafo acíclico necesita límites para la profundidad máxima, nodos únicos, pila de recursión, bytes de respuesta y tiempo de reloj de pared. Al agotarse el presupuesto, utilice un error de aplicación estable o una política de resultados acotados y registre el motivo. No permita que una colección enorme consuma CPU, memoria o ancho de banda de red sin límites.
5. Diseñar la recuperación del cliente
Tras un 508, el cliente debe retener el ID de la solicitud y el contexto del recurso, y dejar de reintentar automáticamente la misma solicitud de profundidad infinita. Puede utilizar profundidad finita, lecturas segmentadas o esperar a que un administrador repare la vinculación. Un valor Retry-After, si se proporciona, no es prueba de que el ciclo haya desaparecido.
6. Concurrencia y almacenamiento en caché
Los recorridos concurrentes del mismo grafo aún necesitan presupuestos y cancelación por solicitud. Las cachés pueden reducir las lecturas de propiedades, pero no pueden eludir la autorización ni reutilizar el grafo de un inquilino para otro. Después de reparar un ciclo, invalide las cachés y los resúmenes afectados mediante versión o token de cambio.
7. Verificación y observabilidad
Pruebe autovinculaciones (self-bindings), ciclos de dos nodos, alias, profundidad finita e infinita, clientes que no entienden 208, agotamiento de presupuesto, condiciones de carrera de cancelación y cambios de permisos. Supervise ciclos detectados, nodos únicos, tiempo de recorrido, bytes de respuesta, tasa de 508, tasa de 208 y reintentos, segmentados por inquilino.
Respuesta modelo
508 es el resultado explícito de terminar un recorrido de vinculación de WebDAV tras encontrar un ciclo. Yo mantendría la pila de recursión activa y un conjunto de ya reportados utilizando IDs de recursos estables; un miembro ya reportado puede usar 208 cuando el cliente lo admite, mientras que regresar a la pila activa produce 508. Cada solicitud tiene presupuestos de profundidad, nodos, tiempo y bytes, y el cuerpo del error contiene solo un código estable y un ID de solicitud. El cliente deja de reintentar la misma solicitud de profundidad infinita y cambia a un recorrido acotado o a la reparación de la vinculación. Las pruebas de carga cubren ciclos, alias, permisos y cancelación, con métricas de ciclos, presupuesto y reintentos.
Errores comunes
- Tratar 508 como cualquier 5xx → El cliente no puede elegir una solución dirigida → Úselo para el contexto de bucle de vinculación.
- Deduplicar por URL → Los alias se omiten o se clasifican erróneamente → Utilice una identidad de recurso estable.
- Tratar 208 como un error de bucle → Un miembro reportado se confunde con una terminación → 208 significa que el miembro ya fue reportado.
- Reintentar 508 indefinidamente → El problema del directorio sigue consumiendo recursos → Reduzca la profundidad o repare la vinculación.
Preguntas de seguimiento
¿Pueden aparecer 208 y 508 en la misma respuesta?
Sí. Algunos miembros pueden marcarse como 208 porque ya fueron reportados; un ciclo posterior aún puede hacer que la operación general termine con 508. La estructura de la respuesta debe seguir la semántica multistatus de WebDAV.
¿Es suficiente un límite de profundidad de recursión?
No. Una colección ancha y poco profunda aún puede generar muchos nodos y una respuesta grande, por lo que también debe limitar los nodos únicos, los bytes, la CPU y el tiempo de reloj de pared.
¿Debería un proxy inverso reescribir 508 a 500?
Por lo general, no. Conserve el estado y los campos de error estables. Si un contrato externo requiere asignación, conserve la causa original en los registros y asegúrese de que el cliente deje de reintentar.
¿Cómo demuestra que los alias siguen funcionando después de la corrección?
Pruebe un grafo acíclico con una vinculación compartida: el mismo ID de recurso alcanzado a través de múltiples rutas debería producir 208 o una deduplicación equivalente, mientras que la autorización se sigue verificando de forma independiente para cada ruta.