Planteamiento y alcance
Un servicio colaborativo de archivos admite WebDAV y permite que los clientes editen el mismo recurso. Las operaciones de escritura, movimiento o eliminación a veces devuelven 423 Locked. Explica la frontera entre 423, 409 y 403; cómo los clientes obtienen y envían un token de bloqueo; cómo manejar la profundidad (depth), el tiempo de espera (timeout), la renovación y las caídas del propietario; y cómo hacer que la recuperación sea observable.
Qué evalúa el entrevistador
- Si explicas 423 como un bloqueo que restringe el recurso de destino en lugar de un error genérico de concurrencia.
- Si comprendes Lock-Token, If, Timeout y UNLOCK en conjunto.
- Si puedes diseñar concesiones (leases), recuperación tras reconexión y autorización sin bloqueos permanentes ni desbloqueos accidentales.
- Si los clientes pueden distinguir entre esperar, readquirir y fallos no reintentables.
Preguntas para aclarar primero
- ¿Es el bloqueo un bloqueo de escritura de WebDAV, una concesión de edición a nivel de aplicación o ambos?
- ¿Abarca un solo recurso o una colección de profundidad infinita (infinity-depth), y cómo heredan o se excluyen los elementos secundarios?
- ¿Dónde se almacena el token y está vinculado al inquilino (tenant), principal, versión del recurso y permisos?
- ¿Quién lo renueva y lo reclama tras desconexiones, caídas de procesos o desfases de reloj (clock skew)?
- ¿Puede un proxy reintentar escrituras y puede el cliente reenviar el cuerpo de forma segura?
Una respuesta en 30 segundos
423 indica que un bloqueo actualmente impide que el método se aplique al recurso de destino; no es una denegación genérica de permisos ni cualquier conflicto de versiones. Yo definiría el alcance, el propietario y el tiempo de concesión restante, requiriendo luego el Lock-Token coincidente en la condición If. El servicio gestiona la concesión y utiliza tiempo monotónico; la renovación está autorizada y acotada, mientras que la expiración recupera el bloqueo tras una caída. El cliente trata el 423 como una espera controlada o una readquisición, sin reenviar a ciegas una escritura no idempotente.
Análisis detallado paso a paso
Paso 1: Definir el límite del protocolo
RFC 4918 utiliza 423 cuando un método no se puede aplicar a un recurso bloqueado. 403 se refiere a la autorización y 409 a un conflicto con el estado actual, por lo que se debe clasificar la causa del bloqueo antes de elegir el estado.
Paso 2: Definir la identidad y el alcance del bloqueo
Almacena la identidad del recurso, la raíz del bloqueo, la profundidad, el propietario, el token, la hora de creación, la concesión, el dominio de permisos y la versión del recurso. Un bloqueo de profundidad infinita puede cubrir elementos secundarios, por lo que el servidor resuelve la herencia antes de cada escritura en lugar de comprobar únicamente la URL.
Paso 3: Validar el Lock-Token
El cliente obtiene un token mediante LOCK y lo envía en la condición If en solicitudes posteriores de escritura, movimiento o eliminación. El servidor comprueba el token, el alcance, el principal y el inquilino. Los tokens ausentes, mal formados o externos reciben un fallo diagnosticable sin exponer al propietario de otro inquilino.
Paso 4: Utilizar concesiones para timeout y renovación
Timeout es un valor solicitado, no una autorización para que el cliente cree una concesión ilimitada. El servidor almacena la expiración utilizando un reloj monotónico, autentica la renovación y limita la duración máxima. La respuesta indica el timeout concedido y el cliente programa la renovación a partir de ese valor. La expiración reclama el bloqueo tras una caída.
Paso 5: Gestionar la desconexión y la recuperación
Tras reconectarse, el propietario consulta el estado del bloqueo y renueva únicamente con un token que siga siendo válido; la caché local no puede demostrar la propiedad. Un reinicio restablece las concesiones desde el almacenamiento duradero. Si no se puede garantizar una restauración segura, invalida el bloqueo y exige la readquisición para que un token antiguo no pueda escribir.
Paso 6: Separar la espera del reintento
El cliente puede mostrar un estado independiente del titular como "el recurso se está editando" y realizar sondeos (polling) con retroceso (backoff) en función de la concesión restante. 423 no es un fallo de red transitorio. Reintenta una escritura solo cuando se confirme que el token, la versión y el cuerpo son reintentables; los proxies no deben reenviar una solicitud no idempotente con un resultado de ejecución desconocido.
Paso 7: Observar y restringir el abuso
Registra el hash del recurso, el alcance del bloqueo, la concesión restante, el motivo del fallo, el hash del principal y el ID de la solicitud. Mide la tasa de 423, la duración de la retención, los fallos de renovación, la recuperación por expiración y el recuento de bloqueos en profundidad por inquilino, tipo de recurso y versión del cliente. Limita el recuento de bloqueos en profundidad, la concesión máxima y los intentos de token para contener el agotamiento y las adivinaciones.
Respuesta de ejemplo de alta calidad
Primero demostraría que 423 es un bloqueo de WebDAV, separándolo de la autorización 403 y del conflicto de estado de la aplicación 409. El servicio de bloqueo almacena de forma duradera el recurso, la profundidad, el principal, el inquilino, el Lock-Token, la concesión otorgada y la versión. Un cliente obtiene el token con LOCK y lo envía en If; el servidor valida conjuntamente el token, el alcance, el principal y los permisos. La concesión utiliza tiempo monotónico del lado del servidor y una duración máxima. Tras una desconexión, el cliente solo puede renovar con un token válido; tras una caída, la expiración reclama el bloqueo. El cliente presenta un estado recuperable de edición ocupada, sondea con retroceso y nunca reintenta a ciegas una escritura con un resultado desconocido. La telemetría de producción cubre la tasa de 423, la duración de retención, los fallos de renovación, la recuperación y el recuento de bloqueos en profundidad, con pruebas para clientes en competencia, reinicios, desfases de reloj y reintentos de proxy.
Errores comunes
- Devolver 423 para cada conflicto de concurrencia, ocultando errores de versión o de permisos.
- Mantener los bloqueos solo en memoria, generando bloqueos permanentes o desbloqueos erróneos tras una caída.
- Aceptar un Timeout ilimitado del cliente en lugar de devolver la concesión otorgada.
- Comparar únicamente cadenas de tokens sin comprobar el alcance, el inquilino y los permisos del principal.
- Permitir que un proxy reenvíe una escritura con efectos secundarios y la aplique dos veces.
Preguntas de seguimiento y respuestas
¿Cuándo deberías usar 423 frente a 409?
Usa 423 cuando un bloqueo efectivo impida el método; usa 409 cuando no exista ningún bloqueo pero la solicitud entre en conflicto con la versión o el estado actual. Ambos necesitan una ruta de recuperación diagnosticable.
¿Cómo se contiene un bloqueo de profundidad infinita?
Restringe sus permisos y cantidad, resuelve la cadena de herencia hasta el destino y recalcula la cobertura para operaciones de mover, copiar y eliminar. Rechaza explícitamente operaciones entre inquilinos o entre colecciones en lugar de asumir la herencia.
¿Puede un administrador forzar el desbloqueo tras una caída?
Solo con autorización explícita y un motivo auditable. Los clientes habituales esperan a la expiración; un desbloqueo forzado invalida el token anterior y registra al operador, el motivo y la versión del recurso.
¿Qué ocurre si los relojes de los servidores no coinciden?
Utiliza tiempo monotónico en un único nodo o en un almacén respaldado por consenso para la expiración, y permite que los clientes se basen en la duración restante concedida. La renovación entre nodos requiere una condición de versión para que dos nodos no puedan extender un mismo bloqueo de forma concurrente.