Entrevista general: ¿Cuándo se debe usar HTTP 208 Already Reported y cómo evitar su uso indebido?

Planteamiento y alcance

Un servicio WebDAV permite que múltiples vinculaciones apunten al mismo recurso. Un cliente envía un PROPFIND con Depth infinity, y el servidor encuentra ese recurso repetidamente en una única respuesta 207 Multi-Status. Explique 208 Already Reported, cuándo emitirlo, cómo manejar clientes antiguos y en qué se diferencia de 508 Loop Detected.

Esta es la extensión de vinculación WebDAV RFC 5842. 208 no es un código de éxito REST genérico para “ya existe”.

Qué está evaluando el entrevistador

• Identificar 208 como una línea de estado dentro de una respuesta 207 Multi-Status, no como el estado de respuesta HTTP independiente.
• Conectar los alias de vinculación, la identidad del recurso y la enumeración repetida.
• Distinguir un recurso ya reportado de un bucle de vinculación real y usar 508 correctamente.
• Diseñar límites de Depth, manejo de capacidades del cliente, análisis de XML y observabilidad.

Preguntas aclaratorias

1. ¿El servicio implementa los métodos de vinculación de RFC 5842 y DAV:resource-id?
2. ¿Los clientes entienden 208, o solo respuestas básicas de WebDAV 207?
3. ¿Es PROPFIND Depth 0, 1 o infinity, y qué límite de servidor aplica?
4. ¿La repetición es causada por vinculaciones, enlaces simbólicos o un ciclo real de padre-hijo?
5. ¿Debe el producto listar cada alias, o solo reportar cada recurso una vez?

Una respuesta de 30 segundos

“208 marca un recurso que ya fue reportado en la misma respuesta 207 Multi-Status, comúnmente cuando las vinculaciones WebDAV causan una enumeración repetida. Elimino duplicados mediante una identidad de recurso estable, devuelvo un propstat completo para la primera aparición y uso 208 para vinculaciones posteriores; un bucle de vinculación que no se puede terminar de forma segura es 508. Para los clientes que no entienden 208, limito Depth o devuelvo un 207 analizable dentro del contrato WebDAV, y registro las razones de desduplicación, profundidad, bucle y truncamiento. Nunca usaría 208 para un resultado REST ordinario de ‘ya existe’.”

Diseño paso a paso

1. Confirmar la capa de respuesta

La respuesta HTTP externa normalmente es 207 Multi-Status. Cada respuesta contiene un URI de recurso y uno o más elementos propstat. 208 es la línea de estado dentro de la respuesta de propiedad DAV correspondiente, lo que indica que el recurso de la vinculación ya se reportó en esta respuesta Multi-Status. No reemplace el 207 externo con 208.

2. Desduplicar por identidad de recurso

Un URI no es necesariamente la identidad de un recurso. Diferentes vinculaciones pueden exponer diferentes URI para un mismo recurso. Utilice DAV:resource-id o un ID interno estable para un conjunto de visitados por recorrido. Emita propiedades completas para el primer encuentro, y luego 208 para vinculaciones posteriores mientras conserva la relación de cada URI.

PROPFIND Depth: infinity
  /alias-a -> resource R: full propstat
  /alias-b -> resource R: 208 Already Reported
  /child   -> resource C: full propstat

3. Mantener 208 en su contexto previsto

208 ahorra cargas útiles de propiedades 207 repetidas y evita que la enumeración de vinculaciones se expanda indefinidamente. No significa un conflicto de inserción en la base de datos, que un reintento idempotente tuvo éxito o un acierto de caché. Una API JSON ordinaria debería elegir en su lugar una semántica explícita de 200, 201, 204 o 409.

4. Distinguir 508 Loop Detected

Si el recorrido encuentra una relación de vinculación que forma un ciclo en lugar de una segunda referencia a un recurso ya completado, detenga la recursión y use 508 Loop Detected. 208 significa que el recurso se reportó exitosamente antes; 508 significa que el procesamiento se detuvo para evitar un bucle infinito. Pruebe los alias, los ciclos reales y los límites de profundidad por separado.

5. Manejar la compatibilidad y los límites de recursos

Negocie u observe la compatibilidad del cliente para 208. Para un cliente antiguo, limite Depth infinity, rechace solicitudes no seguras o devuelva contenido propstat comprensible sin violar la semántica de WebDAV. Limite el recuento de nodos, los bytes de respuesta, el tiempo y la memoria del conjunto de visitados para que un grafo de vinculaciones hostil no pueda agotar el servicio.

6. Observar y recuperar

Registre el ID de solicitud, Depth, recuento de recursos visitados, recuento de 208, recuento de 508, motivo de truncamiento, tamaño de respuesta y capacidad del cliente; nunca registre contenido de archivos ni credenciales. Si el índice de desduplicación falla, trunque de forma segura con un error explícito en lugar de emitir una recursión ilimitada. Mantenga un grafo de vinculaciones reproducible para la depuración de identidades y bucles.

Respuesta modelo de alta calidad

“La respuesta externa sigue siendo 207 Multi-Status; 208 aparece en el estado de un propstat para indicar que el mismo recurso ya fue reportado. Para un PROPFIND con Depth infinity, construyo un conjunto de visitados a partir de la identidad del recurso: la primera vinculación devuelve propiedades completas y los alias posteriores devuelven 208 conservando sus URI. Un ciclo real se detiene con 508. No usaría 208 para un resultado de ya-existe o de reintento de una API genérica. Los clientes más antiguos reciben un límite de profundidad o un rechazo seguro, y la telemetría cubre recursos, tamaño de respuesta, 208, 508 y truncamiento.”

Errores comunes

• Establecer toda la respuesta HTTP en 208 → la estructura de 207 Multi-Status se pierde → coloque 208 en el estado propstat correspondiente.
• Usar URI como clave de recurso → los alias aún duplican el recurso → desduplique por ID de recurso.
• Usar 208 para ya-existe → los clientes REST genéricos lo malinterpretan → use 409 o una respuesta de negocio explícita.
• Tratar cada duplicado como 508 → los alias normales parecen bucles → separe los recursos reportados de los ciclos.
• No establecer un límite de Depth o de respuesta → un grafo de vinculaciones puede agotar la memoria → delimite nodos, tiempo, bytes y tamaño del conjunto de visitados.

Preguntas de seguimiento y respuestas

¿Una entrada 208 todavía necesita un URI?

Sí. Conserve la respuesta para esa vinculación para que el cliente sepa qué URI fue recorrido, pero no repita la carga útil completa de propiedades. El XML debe seguir el contrato de análisis de Multi-Status de WebDAV.

¿Por qué no eliminar las entradas duplicadas por completo?

La eliminación oculta el hecho de que se recorrió un alias y puede parecer una omisión del servidor. 208 preserva la evidencia del recorrido al tiempo que evita datos de propiedades duplicados.

¿Cuándo debería el servidor rechazar Depth infinity?

Rechácelo o limítelo cuando el cliente no pueda analizar 208, el grafo de vinculaciones exceda los límites de recursos o no se pueda construir un conjunto de visitados confiable. Una respuesta acotada es más segura que una salida incompleta o una recursión ilimitada.