HTTP 424 Failed Dependency en servidor: dependencia fallida

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

1. 1

   Localizar en el XML 207 Multi-Status la propiedad o el recurso con el código de error primario

   Requiere herramientas

   Quién:

   Tú como desarrollador o integrador del cliente WebDAV, inspeccionando la respuesta capturada sin repetir escrituras.

   Cómo:

   Abre el cuerpo XML de la respuesta 207 Multi-Status (elemento DAV:multistatus) e identifica todos los bloques DAV:response y DAV:propstat: separa los que llevan HTTP/1.1 424 Failed Dependency de aquel que contiene el estado de fallo distinto a 424 (como 403, 409, 423 o 507).

   Resultado que importa:

   Aíslas el nombre exacto de la propiedad o el URI (DAV:href) que originó el rechazo en cascada.

   Si encuentras un propstat o response hermano con estado 403, 409, 423 o 507, confirma que ese elemento es la causa real y que los elementos en 424 solo reflejan la dependencia abortada.

   Si el servidor devolvió 424 sin ningún otro código de causa primaria en el cuerpo XML, indica un defecto de generación del informe Multi-Status en el servidor WebDAV.

   Evidencia a conservar:

   Conserva el documento XML completo de la petición y de la respuesta 207 Multi-Status con sus elementos DAV:status y DAV:error.

   No manipules ni elimines colecciones en producción para probar: analiza primero el cuerpo XML ya recibido.

   Evidencia: IANA HTTP Status Code Registry · RFC 4918 - WebDAV

2. 2

   Comprobar en peticiones PROPPATCH si el lote intenta alterar una propiedad protegida o en conflicto

   Requiere herramientas

   Quién:

   Tú como persona desarrolladora de la integración WebDAV revisando el cuerpo DAV:propertyupdate enviado.

   Cómo:

   Examina las instrucciones DAV:set y DAV:remove enviadas en el PROPPATCH y verifica cuál de las propiedades devolvió 403 Forbidden (como la precondición cannot-modify-protected-property en DAV:getetag) o 409 Conflict.

   Resultado que importa:

   Determinas qué propiedad concreta impidió que se guardaran las demás propiedades marcadas con 424.

   Si al retirar del lote PROPPATCH la propiedad protegida o inválida el servidor aplica el resto con 200 OK, confirma que el 424 se debía exclusivamente a la atomicidad de PROPPATCH descrita en RFC 4918 sección 9.2.

   Si todas las propiedades son editables según el esquema pero el servidor rechaza el lote, descarta un intento de escritura sobre propiedad protegida e indica revisar permisos o bloqueos.

   Evidencia a conservar:

   Guarda el listado de propiedades incluidas en DAV:propertyupdate y el estado devuelto para cada una.

   Ejecuta cualquier prueba de modificación de propiedades únicamente sobre un recurso de prueba.

   Evidencia: RFC 4918 - WebDAV

3. 3

   Revisar tokens de bloqueo (cabecera If) y permisos de miembros internos en operaciones LOCK de colección

   Sin herramientas especiales

   Quién:

   Tú como administrador del repositorio WebDAV o desarrollador del cliente.

   Cómo:

   Si el 424 aparece asociado al Request-URI de una colección durante un LOCK con Depth: infinity (o sin cabecera Depth), busca en el mismo 207 Multi-Status el elemento DAV:response del miembro interno que devolvió 423 Locked o 403 Forbidden.

   Resultado que importa:

   Verificas qué miembro descendiente tenía un bloqueo activo incompatible o carecía de permisos para el usuario.

   Si el miembro interno reporta 423 Locked (con lock-token-submitted) o 403, confirma por qué el servidor no pudo conceder el bloqueo jerárquico al contenedor raíz y le asignó 424.

   Si ningún miembro interno está bloqueado ni restringido y aun así falla el LOCK con 424, indica escalar la traza al equipo del servidor WebDAV.

   Evidencia a conservar:

   Anota el DAV:href del miembro bloqueado, la cabecera If enviada y los propietarios de bloqueos activos en DAV:lockdiscovery.

   Evidencia: RFC 4918 - WebDAV

Un código solo tiene significado dentro del producto y la versión correctos.

Definido en la sección 11.4 de RFC 4918 e inscrito en el registro IANA dentro de la clase 4xx (Client Error), el código HTTP 424 (Failed Dependency) señala que el servidor WebDAV abortó una operación sobre un recurso o propiedad porque dependía de otra acción en la misma petición y esa acción previa falló. Ocurre de forma típica en respuestas 207 (Multi-Status) de PROPPATCH (que es atómico: si falla el cambio de una propiedad con 403 o 409, el resto de propiedades reciben 424) y de LOCK con alcance profundo cuando un miembro interno impide conceder el bloqueo al Request-URI. Por sí solo, 424 nunca indica la causa raíz ni demuestra un fallo del servidor.

• Precauciónverificada con fuente

  No reintentes en bucle el mismo lote PROPPATCH ni la misma petición LOCK esperando que desaparezca un HTTP 424: mientras no corrijas la propiedad o el miembro que falló con 403, 409 o 423, la dependencia volverá a fallar siempre.

  Evidencia: RFC 4918 - WebDAV

• Seguroverificada con fuente

  No elimines bloqueos activos ajenos ni eleves permisos globales en una colección WebDAV sin verificar antes en el cuerpo 207 Multi-Status qué miembro concreto originó el rechazo.

  Evidencia: RFC 4918 - WebDAV

1. 1

   IANA HTTP Status Code Registry

   Internet Assigned Numbers Authority · 2025 · standard

2. 2

   RFC 4918 - WebDAV

   IETF / RFC Editor · 2007 · standard