Entrevista general: ¿Cuándo es correcto HTTP 508 Loop Detected y cómo se previenen los ciclos de recorrido en WebDAV?

Planteamiento y alcance

Un servicio WebDAV permite múltiples vinculaciones (bindings) entre colecciones. Un cliente envía un PROPFIND con Depth: infinity; el servidor llega a una colección que ya está en la ruta de recorrido y devuelve 508. Explique el significado exacto de 508, distíngalo de un bucle genérico de reintentos, describa cuándo es apropiado 208 Already Reported, evite el agotamiento de recursos y defina el comportamiento del cliente.

Esto combina la semántica de estados HTTP, recorrido de grafos, compatibilidad de protocolos y límites de seguridad. La RFC 5842 define 508 para terminar una operación de profundidad infinita tras encontrar un bucle; la IANA registra 508 bajo la RFC 5842.

Qué está evaluando el entrevistador

• Si sabe que 508 se refiere a vinculaciones de WebDAV y Depth: infinity, no a cualquier fallo de redirección.
• Si puede modelar recursos, vinculaciones URI, rutas y colecciones visitadas como un grafo.
• Si distingue entre continuar con 208 para un recurso repetido y fallar toda la operación con 508 cuando el cliente carece de soporte para 208.
• Si proporciona terminación determinista, presupuestos, observabilidad y fallback en lugar de limitarse a decir "añadir un conjunto de visitados".

Preguntas para aclarar primero

1. ¿Qué método y valor de Depth se utilizan? La semántica concierne al recorrido recursivo.
2. ¿Implementa el servidor las vinculaciones de la RFC 5842 y anuncia capacidades DAV? ¿Entiende el cliente 208?
3. ¿Se desduplica un nodo por ID de recurso, URI canónico o ruta de vinculación? Un recurso puede tener múltiples URIs.
4. ¿Debe la respuesta contener resultados parciales o la operación debe fallar de forma atómica?
5. ¿Qué presupuestos de nodos, tamaño de cuerpo, tiempo de CPU y autorización restringen los recorridos profundos hostiles?

Estructura de respuesta en 30 segundos

Primero delimite el significado: 508 indica que un servidor terminó una operación Depth: infinity de WebDAV tras encontrar un ciclo de vinculación; no es un estado genérico de reintento HTTP. Modele las vinculaciones como un grafo y detecte aristas de retroceso por la identidad del recurso. Si el cliente entiende 208, reporte el recurso una vez y continúe con una respuesta multistatus; de lo contrario, 508 puede fallar la operación de forma clara. Aplique presupuestos de nodos, profundidad, bytes y tiempo, registre el ciclo y detenga los reintentos automáticos del cliente.

Respuesta paso a paso

1. Modele el grafo de recursos, no solo las cadenas de URL

Los nodos son recursos o colecciones y las aristas son vinculaciones. Un URI es una ruta de acceso, no necesariamente una identidad de recurso; un recurso puede tener varias vinculaciones. Conserve el ID del recurso, la ruta actual y la ruta padre para desduplicación, auditoría y diagnóstico.

2. Use un estado explícito de DFS o BFS

Mantenga la pila de recursión activa y un conjunto de reportados. Antes de entrar a un nodo, compruebe si ya está en la pila activa; eso es una arista de retroceso. Llegar al mismo recurso a través de otra ruta puede tratarse como ya reportado según la capacidad del protocolo en lugar de expandirse indefinidamente.

visit(node, path):
  if node in activePath: return CYCLE
  if node in reported: return ALREADY_REPORTED
  budget.consume(node)
  activePath.add(node)
  report(node)
  for child in children(node): visit(child, path + child)
  activePath.remove(node)

activePath identifica un ciclo real, mientras que reported evita salidas duplicadas a través de múltiples vinculaciones. Un solo conjunto no puede representar de forma segura ambos casos.

3. Seleccione 208 o 508 según la capacidad del cliente

Si el cliente anuncia soporte para la extensión de vinculación y 208, el servidor puede devolver la primera aparición normalmente, marcar las vinculaciones posteriores como Already Reported en una respuesta multistatus y omitir sus descendientes. Si el cliente no entiende 208, la RFC 5842 proporciona una ruta de compatibilidad en la que la operación de profundidad infinita falla con 508. No disfrace el fallo como 200.

4. Establezca presupuestos deterministas y límites de seguridad

Incluso un grafo acíclico puede agotar la CPU, la memoria o el espacio de respuesta. Establezca límites máximos de nodos, longitud de ruta activa, bytes totales, tiempo de reloj (wall-clock time) y concurrencia. Al agotarse el presupuesto, registre el motivo y devuelva un fallo permitido claro en lugar de reintentar. Verifique la autorización a través de las vinculaciones de inquilinos (tenants) para que los nodos ocultos no se filtren a través de una respuesta multistatus.

5. Gestione escrituras y cambios de topología concurrentes

BIND, REBIND y UNBIND modifican el grafo. Recorra una instantánea o versión consistente para que un cambio de topología no invalide la detección a mitad de la operación. Antes de crear una vinculación posiblemente cíclica, ejecute una verificación de alcanzabilidad o exija una precondición explícita que permita ciclos; mantenga la comprobación y la confirmación (commit) dentro del mismo límite transaccional.

6. Haga que los clientes detengan reintentos perjudiciales

508 significa que la operación solicitada falló; los clientes no deben tratarlo como un 503 y reintentar a ciegas con backoff. Lea el cuerpo y el ID de correlación, reduzca la profundidad, repare la vinculación o consulte las capacidades. Un proxy que asigne 508 a un error común debe preservar el estado original y los campos de diagnóstico.

Ejemplo de respuesta de alta calidad

Yo modelaría las vinculaciones como un grafo dirigido y distinguiría la identidad del recurso del URI de acceso. Para Depth: infinity, utilizaría la pila de recursión activa para detectar aristas de retroceso y un conjunto de reportados para suprimir salidas duplicadas cuando múltiples vinculaciones alcanzan el mismo recurso; esos conjuntos tienen significados diferentes. Recorrería una vista consistente con presupuestos de nodos, profundidad, bytes de respuesta y tiempo.

Cuando un cliente anuncia soporte para la RFC 5842 y 208, se devuelve el primer recurso en una respuesta multistatus 207, se marcan los duplicados posteriores como Already Reported y se omiten sus descendientes. Para un cliente que no entiende 208, se termina toda la operación de profundidad infinita con 508 según lo especificado por la ruta de compatibilidad. 508 no es un error genérico de reintento, por lo que los clientes deben detener los reintentos automáticos y reparar el grafo o reducir la profundidad. Aplique autorización, métricas y registros de correlación para evitar que los ciclos y los recorridos profundos se conviertan en vectores de DoS.

Modos de fallo comunes

• Considerar 508 como un agotamiento de reintentos de reverse-proxy o un bucle genérico de redirección de URL.
• Desduplicar únicamente por la cadena URI y omitir múltiples vinculaciones a un mismo recurso.
• Usar solo un conjunto global de visitados, confundiendo recursos compartidos con aristas de retroceso o perdiendo la distinción entre 208/508.
• Aceptar Depth: infinity sin presupuestos de nodos, bytes, tiempo y autorización.
• Reintentar automáticamente ante un 508 y gastar recursos repetidamente en la misma topología.
• Olvidar la negociación de capacidades, las respuestas multistatus 207 o las condiciones de carrera en escrituras.

Preguntas de seguimiento y respuestas de referencia

¿Cuál es el límite entre 508 y 208?

208 reporta un recurso visto previamente cuando el cliente entiende la extensión de vinculación, permitiendo que el resto de la operación continúe. 508 termina toda la operación de profundidad infinita tras encontrar un ciclo, comúnmente para un cliente que no puede usar 208.

¿Por qué no usar únicamente un URI como clave de visitados?

Varios URIs pueden vincularse a un solo recurso, por lo que el rastreo exclusivo por URI repite el recorrido. La ruta sigue siendo importante para el diagnóstico, así que conserve tanto la identidad del recurso como el contexto de la ruta.

¿Cómo se evita TOCTOU entre una comprobación y una escritura?

Ejecute la validación de alcanzabilidad y la confirmación de la vinculación en una sola transacción o instantánea versionada. Si la atomicidad abarca múltiples nodos, falle bajo una condición de versión y vuelva a comprobar.

¿Debe un cliente reintentar después de un 508?

No a ciegas. La topología actual hizo fallar la operación; reduzca la profundidad, repare el ciclo u obtenga información sobre las capacidades. Reintente solo después de que la topología haya cambiado deliberadamente.

¿Cómo se realizan pruebas para evitar falsos positivos en la detección de ciclos?

Use fixtures para un DAG acíclico, un recurso compartido, un ciclo de vinculación y un límite de profundidad. Valide mediante aserciones los recuentos de resultados, códigos de estado, presupuestos de recorrido, registros de auditoría y límites de tamaño de respuesta.

¿Se aplica 508 a cada ciclo de llamadas de microservicios?

No. Su significado estandarizado proviene de WebDAV RFC 5842. Otros bucles de servicios necesitan su propio contrato de error; conservar un 5xx no otorga a la respuesta la semántica de WebDAV 508.