Resumen

  • Cada bloqueo WebDAV recibe del servidor un token único. Incluirlo en If demuestra que la solicitud conoce ese identificador; no autentica al emisor ni le concede permiso de escritura.
  • La decisión válida combina controles independientes: principal autenticado, privilegio aplicable, recursos realmente afectados, condiciones y ETags, bloqueos directos o heredados, relación con el creador y estado en el instante de confirmar.
  • Un timeout lo elige finalmente el servidor, un MOVE cambia el ámbito y un UNLOCK puede dejar otros bloqueos compartidos. Por eso el token no es un arrendamiento portátil ni una prueba completa de control.

Una mañana distinta para el mismo token

El lunes, una aplicación obtiene un bloqueo exclusivo sobre un documento. El servidor devuelve un token y la aplicación lo guarda. El martes, el documento se mueve a otra colección, el usuario pierde el privilegio de escritura y un administrador elimina el bloqueo antiguo durante una recuperación. El miércoles, un proceso rezagado presenta la cadena original en una solicitud PUT.

¿Qué debería importar más: que el token fue genuino cuando se creó o que la situación actual ya no le atribuye ningún poder?

La respuesta de RFC 4918 es inequívoca. Al modificar un recurso bloqueado, el servidor comprueba que el principal autenticado coincide con quien creó el bloqueo, además de exigir el token válido. Tener el bloqueo tampoco otorga todos los privilegios de modificación. La autenticación y la autorización normales siguen vigentes.

El ejemplo revela la frontera constitucional del mecanismo. El token es una referencia a una decisión anterior del servidor. La escritura es una decisión presente. Entre ambas pueden cambiar la identidad, la política, el espacio de nombres, el bloqueo o la versión del recurso. El servidor que vuelve a comprobar esos hechos no traiciona el bloqueo; evita que el pasado gobierne el presente.

Un identificador muy fuerte para una afirmación muy pequeña

WebDAV incorporó a HTTP operaciones de autoría remota, propiedades, colecciones, movimientos de nombres y prevención de colisiones. Su bloqueo de escritura reduce el riesgo de que un autor reemplace sin saberlo la actualización de otro.

El servidor genera exactamente un token único para cada bloqueo. Los clientes no deben analizarlo para extraer significado. RFC 4918 exige que las URI de token sean únicas entre todos los recursos y a lo largo del tiempo. Una creación de bloqueo devuelve la cadena tanto en la cabecera de respuesta Lock-Token como en el cuerpo.

Esa unicidad no es una delegación. Solo permite encontrar el registro correcto sin confundirlo con otro. Además, la propiedad DAV:lockdiscovery puede hacer visibles los bloqueos activos. Un diseño que use la oscuridad del token como defensa transforma una propiedad consultable o un registro de diagnóstico en un canal de adquisición de derechos.

La norma recomienda URN UUID y mantiene registrado opaquelocktoken, pero admite cualquier URI única. RFC 9562 aconseja aleatoriedad criptográficamente segura cuando se busca que un UUID sea difícil de adivinar. La entropía protege contra la predicción; no sabe si el principal puede modificar contenido, propiedades o miembros de una colección.

Conviene nombrar las funciones por separado:

  • el token distingue un bloqueo;
  • su presencia acredita conocimiento de la cadena;
  • la autenticación establece quién habla;
  • la política establece qué puede hacer;
  • el modelo WebDAV determina qué bloqueos y condiciones afectan la operación;
  • el repositorio decide si el estado sigue siendo confirmable.

Cuanto más se intenta meter estas funciones en una sola cadena, menos auditable resulta el sistema.

El creador tiene una relación especial, no soberanía

Quien crea el bloqueo puede coordinar modificaciones bajo ese bloqueo, siempre que conserve los permisos ordinarios. El servidor también puede permitir a propietarios de recursos, administradores u otros principales privilegiados destruir un bloqueo.

RFC 3744 separa derechos que suelen quedar escondidos tras la palabra “escritura”. DAV:write-content cubre el contenido de un recurso existente. DAV:write-properties cubre propiedades muertas. DAV:bind controla la creación de pertenencia en una colección, como un PUT dirigido a una URI todavía no asignada. DAV:unlock permite que otro principal ejecute UNLOCK.

Así se evitan dos excesos simétricos. El usuario autorizado no puede ignorar el bloqueo ajeno. El portador del token no puede ignorar la ACL. El administrador puede recuperar disponibilidad, pero su intervención aparece como una excepción atribuida, no como si hubiera sido el creador.

Heng Lu insiste en no confundir el registro con la autoridad que produce realidad. Aquí el token registra una relación de coordinación. El derecho efectivo nace de la identidad, la política y el componente que ejecuta contra el estado actual. Convertir el registro en mando sería pedir al mecanismo que exceda su especificación mínima.

La doble vida de If

El campo WebDAV If es condición y también canal de entrega de tokens.

Como expresión condicional, agrupa tokens de estado y ETags. Dentro de una lista, las condiciones se combinan con AND. Varias listas ofrecen alternativas OR. Not niega el elemento siguiente. Las listas sin etiqueta se aplican a la Request-URI; las listas etiquetadas nombran otro recurso.

Como canal de entrega, la simple aparición del token en If cuenta como presentación al servidor. Ese hecho no depende de que la lista que lo contiene sea la alternativa que finalmente da verdadero. El protocolo necesita ambas nociones porque una operación puede afectar varios recursos y expresar varias rutas condicionales.

Una pasarela que “simplifica” el encabezado a la rama verdadera puede eliminar un token requerido. Un registro que solo anota “token encontrado” puede ocultar que el ETag era falso. Por eso la telemetría debe conservar por separado qué valores fueron presentados y qué condiciones se evaluaron.

Los resultados 412 y 423 tampoco son sinónimos. Una condición If falsa conduce a 412 Precondition Failed, después de comprobar autorización. Si falta el token necesario para un recurso bloqueado que la operación afectaría, 423 Locked con lock-token-submitted describe ese defecto. Mezclarlos impide distinguir una vista obsoleta de una omisión de coordinación.

Lock-Token cumple funciones específicas: devolver el identificador de un nuevo LOCK e indicar en UNLOCK cuál debe retirarse. Para PUT, PROPPATCH, COPY, MOVE y DELETE, la entrega de tokens se realiza a través de If.

La ruta visible no define todo el alcance

Todo bloqueo tiene raíz, ámbito, tipo y profundidad. El bloqueo creado directamente sobre una URL es directo. Uno de profundidad infinita en una colección alcanza indirectamente a sus descendientes y a los miembros que se incorporen después.

Esta herencia desmonta el control superficial. La solicitud puede nombrar un archivo sin mencionar la colección que impone el bloqueo. El servidor debe resolver el espacio de nombres y reunir todos los bloqueos aplicables antes de decidir.

LOCK admite profundidad cero o infinita; si se omite, se considera infinita. Un intento sobre una jerarquía no puede dejar algunos miembros bloqueados y otros no por un fallo intermedio. El resultado es integral para el ámbito solicitado, y Multi-Status puede identificar el impedimento.

Las operaciones de origen y destino añaden más superficies. COPY o MOVE pueden tocar la fuente, la colección de destino y un recurso que se sobrescribe. DELETE cambia también la pertenencia del padre. RFC 4918 exige presentar los tokens necesarios para todos los recursos que deben quedar desbloqueados durante la operación.

MOVE aporta la prueba decisiva contra el token portátil. El bloqueo directo no acompaña al recurso a su nueva URL. Al salir de una colección puede perder un bloqueo indirecto; al entrar en otra puede adquirirlo. El mismo contenido queda sometido a otra topología de control sin que su antiguo token adquiera derecho de viaje.

Por eso un motor de políticas necesita el conjunto completo de recursos afectados. Validar en un borde solo la URI visible y dejar el resto al repositorio crea dos decisiones incompatibles.

Compartir no fusiona identidades ni bloqueos

Los bloqueos compartidos permiten que coexistan otros compatibles, pero cada LOCK exitoso crea un bloqueo separado con token propio. No hay un token comunitario que represente a todos los colaboradores.

El refresco de uno no extiende los demás. UNLOCK elimina el identificado sin garantizar que el recurso quede libre. Otro bloqueo compartido o uno indirecto puede seguir activo.

La aplicación debe aportar las reglas que WebDAV no pretende definir: cómo se fusionan cambios, quién revisa, qué ocurre ante desacuerdo y qué versión es definitiva. “Compartido” describe compatibilidad técnica, no autoridad colectiva.

Un tablero binario pierde el dato importante. Debe mostrar creador, raíz, profundidad, relación directa o heredada, tiempo anunciado y resultado de cada retirada.

El reloj del cliente no crea un contrato

El cliente puede sugerir en Timeout cuánto desea conservar el bloqueo. El servidor decide la duración real y puede ignorar la petición. La respuesta del servidor, no la expectativa local, establece el tiempo anunciado.

Para refrescar, el cliente envía LOCK sin cuerpo y un único token en If. El servidor ignora Depth, reinicia el contador si acepta, no modifica los otros bloqueos compartidos y devuelve DAV:lockdiscovery actualizado. No entrega un nuevo Lock-Token.

La ausencia de error no se puede inventar: si el refresco falla, el cliente no debe asumir que ocurrió. Tampoco puede garantizar que el bloqueo vivirá hasta el último segundo. Un override, una caída o pérdida de estado puede terminarlo antes. Y el fin del cálculo local no prueba que el servidor ya lo haya eliminado.

El timeout es, por tanto, una disciplina de renovación y limpieza. Antes de confirmar una operación relevante hay que presentar el token y validar la versión y el estado actuales.

Un camino de decisión reconstruible

Una implementación madura conserva nueve pasos visibles:

  1. autenticar al principal;
  2. autorizar la operación exacta;
  3. resolver fuente, destino, padres y recursos sobrescritos;
  4. descubrir bloqueos directos, indirectos, exclusivos y compartidos;
  5. analizar listas If, ETags, Not y alternativas sin perder entregas;
  6. verificar todos los tokens requeridos;
  7. comprobar creador o override autorizado;
  8. reevaluar estado al confirmar y ejecutar con la atomicidad prevista;
  9. registrar si falló identidad, privilegio, condición, token, alcance o commit.

El registro puede usar una huella con clave en lugar de exponer la cadena. Debe enlazarla con principal, método, recursos, raíces, profundidad, timeout efectivo, versión final y código.

Las pruebas decisivas cruzan las fronteras: token correcto con principal equivocado; permiso correcto sin token; token correcto con ETag falso; colección de profundidad infinita con miembro nuevo; bloqueo jerárquico que falla sin residuo parcial; MOVE hacia destino bloqueado; dos bloqueos compartidos de los que solo uno se refresca o retira; intervención administrativa atribuida; camino de almacenamiento que intenta saltarse WebDAV.

Los bloqueos reducen una clase de actualizaciones perdidas. No resuelven deadlocks de negocio, fusiones semánticas, escrituras directas al repositorio ni transacciones distribuidas. Mantener ese límite permite confiar en lo que sí hacen.

Fuentes