Servicio HTTP y WebDAV con código 423: recurso bloqueado

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

1. 1

   Inspeccionar el cuerpo XML DAV:error o 207 Multi-Status para extraer la precondición y el D:href bloqueado

   Sin herramientas especiales

   Quién:

   Tú como persona desarrolladora o administradora analizando la respuesta HTTP 423 del servidor WebDAV.

   Cómo:

   Lee el cuerpo XML de la respuesta 423 (o el bloque response con estado HTTP/1.1 423 Locked dentro de un 207 Multi-Status) e identifica si el elemento D:error contiene lock-token-submitted o no-conflicting-lock, anotando cada URI listada en sus elementos hijos D:href.

   Resultado que importa:

   Identificación exacta de la URI raíz que impide la operación y del tipo de conflicto de bloqueo.

   Si D:href dentro de lock-token-submitted apunta a una colección padre distinta de la Request-URI enviada, confirma un bloqueo indirecto depth-infinity heredado de esa colección superior.

   Si el elemento devuelto es no-conflicting-lock durante un método LOCK, confirma que ya existe un bloqueo activo incompatible sobre ese recurso o uno de sus miembros e indica consultar la propiedad lockdiscovery.

   Evidencia a conservar:

   Conserva la petición HTTP (método, Request-URI y cabecera Destination si existe) y el XML D:error completo sin credenciales.

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

2. 2

   Verificar el envío del lock token en la cabecera If para todos los recursos modificados

   Sin herramientas especiales

   Quién:

   Tú revisando las cabeceras de petición generadas por el cliente WebDAV o script de sincronización.

   Cómo:

   Si el principal autenticado es el titular del bloqueo y desea modificar el recurso sin desbloquearlo, comprueba que la petición incluya la cabecera If con el token urn:uuid correspondiente (en formato Tagged-List para la URI bloqueada o No-Tag-List), aportando dos tokens si un MOVE altera tanto un origen como un destino bloqueados, pero solo el del destino en un COPY.

   Resultado que importa:

   Cumplimiento de la regla de envío de tokens de RFC 4918 sección 7.5 para evitar colisiones entre programas del mismo usuario.

   Si al añadir en la cabecera If el lock token del recurso o de la colección padre la operación devuelve 200 OK, 201 Created o 204 No Content, confirma que faltaba presentar el token y descarta un fallo del servidor.

   Si el cliente desconoce el token o el bloqueo pertenece a otra sesión que quedó colgada, indica valorar la liberación mediante el método UNLOCK.

   Evidencia a conservar:

   Guarda la traza con la cabecera If probada (formato Tagged-List o No-Tag-List) y el código HTTP resultante.

   Evidencia: RFC 4918 - WebDAV

3. 3

   Liberar un bloqueo obsoleto mediante el método UNLOCK y la cabecera Lock-Token en el alcance correcto

   Sin herramientas especiales

   Quién:

   Tú como titular del bloqueo o persona administradora con permisos sobre el recurso WebDAV.

   Cómo:

   Cuando el bloqueo ya no deba mantenerse, envía una petición HTTP UNLOCK dirigida a una Request-URI dentro del alcance del bloqueo incluyendo la cabecera Lock-Token con el identificador entre paréntesis angulares (por ejemplo Lock-Token: <urn:uuid:...>).

   Resultado que importa:

   Eliminación protocolaria del bloqueo específico en el servidor WebDAV con respuesta esperada 204 No Content.

   Si el método UNLOCK responde 204 (No Content), confirma que ese bloqueo ha quedado eliminado y que puedes reintentar la operación original.

   Si UNLOCK devuelve 400 (Bad Request por falta de token), 403 (Forbidden por falta de permisos del principal) o 409 (Conflict con lock-token-matches-request-uri porque la URI está fuera del alcance o el bloqueo ya expiró), indica escalar al administrador del servidor WebDAV.

   Evidencia a conservar:

   Registra la petición UNLOCK, la URI empleada y el estado HTTP devuelto (204, 400, 403 o 409).

   No elimines por la fuerza bloqueos activos de otros usuarios ni desactives controles de autenticación sin confirmar antes qué proceso o sesión está editando el recurso.

   Evidencia: RFC 4918 - WebDAV

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

En el registro oficial HTTP de IANA y en RFC 4918 (WebDAV, secciones 7.5, 9.11, 11.3 y 16), el servidor devuelve 423 (Locked) cuando el recurso de origen o de destino de un método está sujeto a un bloqueo activo incompatible con la petición. RFC 4918 establece que la respuesta debe incluir un elemento XML de precondición o postcondición como lock-token-submitted (con al menos un elemento href que identifica la URI bloqueada, incluido un bloqueo depth-infinity heredado de una colección padre) o no-conflicting-lock cuando falla una petición LOCK. El código 423 describe un estado de concurrencia del protocolo WebDAV y por sí solo nunca demuestra un fallo del servidor ni del almacenamiento.

• Precauciónverificada con fuente

  No fuerces la eliminación de bloqueos WebDAV en servidores compartidos ni sobrescribas archivos sin verificar antes quién posee el bloqueo: RFC 4918 exige presentar el lock token precisamente para evitar que un programa pise los cambios no guardados de otro.

  Evidencia: RFC 4918 - WebDAV

• Seguroverificada con fuente

  No confundas la respuesta exitosa 204 (No Content) de un método UNLOCK con la ausencia total de otros bloqueos si el recurso admitía bloqueos compartidos, y oculta siempre las cabeceras Authorization antes de adjuntar trazas HTTP.

  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