Lease Blob

La Lease Blob operación crea y administra un bloqueo en un blob para las operaciones de escritura y eliminación. La duración del bloqueo puede ser de 15 a 60 segundos, o puede ser infinita. En versiones anteriores a 2012-02-12, la duración del bloqueo es de 60 segundos.

Importante

A partir de la versión 2012-02-12, algunos comportamientos de la operación Lease Blob son distintos de los de las versiones anteriores. Por ejemplo, en versiones anteriores, podría renovar una concesión después de publicarla. A partir de la versión 2012-02-12, se produce un error en esta solicitud de concesión, pero las llamadas que usan versiones Lease Blob anteriores de siguen siendo correctas. Para obtener una lista de los cambios en el comportamiento de esta operación, consulte la sección "Comentarios" más adelante en este artículo.

Puede llamar a la Lease Blob operación en uno de los modos siguientes:

  • Acquire, para solicitar una nueva concesión.

  • Renew, para renovar una concesión existente.

  • Change, para cambiar el identificador de una concesión existente.

  • Release, para liberar la concesión si ya no es necesaria, de modo que otro cliente pueda adquirir inmediatamente una concesión en el blob.

  • Break, para finalizar la concesión, pero asegúrese de que otro cliente no pueda adquirir una nueva concesión hasta que haya expirado el período de concesión actual.

Solicitud

Puede construir la Lease Blob solicitud como se indica a continuación. Se recomienda HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento.

URI de solicitud de método PUT Versión de HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease HTTP/1.1

URI del servicio de almacenamiento emulado

Al realizar una solicitud en el servicio de almacenamiento emulado, especifique el nombre de host del emulador y Azure Blob Storage puerto como 127.0.0.1:10000, seguido del nombre de la cuenta de almacenamiento emulada.

URI de solicitud de método PUT Versión de HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=lease HTTP/1.0

HTTP/1.1

Para más información, consulte Uso del emulador de Azurite para el desarrollo local de Azure Storage.

Parámetros del identificador URI

Puede especificar el siguiente parámetro adicional en el URI de solicitud.

Parámetro Descripción
timeout Opcional. El parámetro timeout se expresa en segundos. Para más información, consulte Configuración de tiempos de espera para las operaciones de Blob Storage.

Encabezados de solicitud

En la tabla siguiente se describen los encabezados de solicitud requeridos y opcionales.

Encabezado de solicitud Descripción
Authorization Necesario. Especifica el esquema de autorización, el nombre de la cuenta y la firma. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
Date o x-ms-date Necesario. Especifica la hora universal coordinada (UTC) de la solicitud. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
x-ms-version Opcional. Especifica la versión de la operación que se utiliza para esta solicitud. Para obtener más información, vea Versiones de los servicios de Azure Storage.
x-ms-lease-id: <ID> Obligatorio para renovar, cambiar o liberar la concesión.

Puede especificar el valor de x-ms-lease-id en cualquier formato de cadena GUID válido. Consulte Guid Constructor (String) para obtener una lista de formatos válidos.
x-ms-lease-action: <acquire ¦ renew ¦ change ¦ release ¦ break> acquire: solicita una nueva concesión. Si el blob no tiene una concesión activa, Blob Storage crea una concesión en el blob y devuelve un nuevo identificador de concesión. Si el blob tiene una concesión activa, solo puede solicitar una nueva concesión mediante el identificador de concesión activo. Sin embargo, puede especificar un nuevo x-ms-lease-duration, incluido el negativo (-1) para una concesión que nunca expira.

renew: renueva la concesión. Puede renovar la concesión si el identificador de concesión especificado en la solicitud coincide con el asociado al blob. Tenga en cuenta que la concesión se puede renovar incluso si ha expirado, siempre y cuando el blob no se haya modificado o concedido de nuevo desde la expiración de esa concesión. Cuando se renueva una concesión, el reloj que controla su duración se reinicia.

change: versión 2012-02-12 y posteriores. Cambia el identificador de concesión de una concesión activa. Debe change incluir el identificador de concesión actual en x-ms-lease-idy un nuevo identificador de concesión en x-ms-proposed-lease-id.

release: libera la concesión. Puede liberar la concesión si el identificador de concesión especificado en la solicitud coincide con el asociado al blob. La liberación de la concesión permite a otro cliente adquirir inmediatamente la concesión del blob, en cuanto se complete la versión.

break: interrumpe la concesión si el blob tiene una concesión activa. Una vez interrumpida una concesión, no se puede renovar. Cualquier solicitud autorizada puede interrumpir la concesión; no es necesario que la solicitud especifique un identificador de concesión que coincida. Cuando se interrumpe una concesión, el período de interrupción de concesión puede transcurrir, durante el cual break y release son las únicas operaciones de concesión que puede realizar en el blob. Cuando una concesión se interrumpe correctamente, la respuesta indica el intervalo en segundos que debe transcurrir hasta que se pueda obtener una nueva concesión.

También se puede liberar una concesión interrumpida, en cuyo caso otro cliente puede adquirir inmediatamente la concesión en el blob.
x-ms-lease-break-period: N Opcional. Versión 2012-02-12 y posteriores. Para una operación break, es la duración propuesta de la concesión (entre 0 y 60 segundos) durante la cual la concesión debería continuar antes de interrumpirla. Este período de interrupción solo se usa si es más corto que el tiempo restante en la concesión. Si es más largo, se utiliza el tiempo restante de la concesión. Una nueva concesión no estará disponible antes de que haya expirado el período de interrupción, pero la concesión se puede mantener durante más tiempo que el período de interrupción. Si este encabezado no aparece con una break operación, se interrumpe una concesión de duración fija después de que transcurre el período de concesión restante y se interrumpe inmediatamente una concesión infinita.
x-ms-lease-duration: -1 ¦ n seconds Versión 2012-02-12 y posteriores. Solo se permiten y requieren en una acquire operación. Especifica la duración de la concesión, en segundos, o bien un valor negativo (-1) para una concesión que no expira nunca. Un concesión no infinita puede durar entre 15 y 60 segundos. Una duración de concesión no se puede cambiar mediante renew o change.
x-ms-proposed-lease-id: <ID> Versión 2012-02-12 y posteriores. Opcional para acquire, y es necesario para change. Identificador de concesión propuesto, con formato de cadena de GUID. Blob Storage devuelve 400 (Invalid request) si el identificador de concesión propuesto no tiene el formato correcto. Consulte Guid Constructor (String) para obtener una lista de formatos válidos.
Origin Opcional. Especifica el origen del que se emitirá la solicitud. La presencia de este encabezado da lugar a encabezados de uso compartido de recursos entre orígenes (CORS) en la respuesta. Consulte Compatibilidad con CORS para los servicios de almacenamiento para obtener más información.
x-ms-client-request-id Opcional. Proporciona un valor opaco generado por el cliente con un límite de caracteres de 1 kibibyte (KiB) que se registra en los registros cuando se configura el registro. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes que recibe el servidor. Para obtener más información, vea Supervisar Azure Blob Storage.

Esta operación también admite el uso de encabezados condicionales para ejecutar la operación, solo si se cumple una condición especificada. Para más información, consulte Especificación de encabezados condicionales para las operaciones de Blob Storage.

Cuerpo de la solicitud

Ninguno.

Solicitud de ejemplo

La solicitud de ejemplo siguiente muestra cómo adquirir una concesión:

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-lease-action: acquire  
x-ms-lease-duration: -1  
x-ms-proposed-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-date: <date>  
Authorization: SharedKey testaccount1:esSKMOYdK4o+nGTuTyeOLBI+xqnqi6aBmiW4XI699+o=  
  

Response

La respuesta incluye un código de estado HTTP y un conjunto de encabezados de respuesta.

status code

Los códigos de estado correctos devueltos para las operaciones de concesión son los siguientes:

  • Acquire: una operación correcta devuelve el código de estado 201 (Creada).

  • Renew: una operación correcta devuelve el código de estado 200 (Correcto).

  • Change: una operación correcta devuelve el código de estado 200 (Correcto).

  • Release: una operación correcta devuelve el código de estado 200 (Correcto).

  • Break: una operación correcta devuelve el código de estado 202 (Aceptada).

Para obtener información sobre los códigos de estado, vea Códigos de estado y de error.

Encabezados de respuesta

La respuesta para esta operación incluye los encabezados siguientes. La respuesta también puede incluir encabezados HTTP adicionales y estándar. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1.

Sintaxis Descripción
ETag Contiene un valor que puede usar para realizar operaciones condicionalmente. Consulte Especificación de encabezados condicionales para operaciones de Blob Storage para obtener más información.

Este encabezado se devuelve para las solicitudes realizadas en la versión 2013-08-15 y posteriores, y el ETag valor está entre comillas.

La Lease Blob operación no modifica esta propiedad.
Last-Modified La fecha y la hora en la que se modificó por última vez el blob. Para obtener más información, vea Representación de valores de fecha y hora en encabezados.

Cualquier operación de escritura realizada en el blob, incluidas las actualizaciones de los metadatos o las propiedades del blob, cambia la hora de la última modificación del blob. La Lease Blob operación no modifica esta propiedad.
x-ms-lease-id: <id> Al solicitar una concesión, Blob Storage devuelve un identificador de concesión único. Mientras la concesión está activa, se debe incluir el identificador de concesión con cualquier solicitud para escribir en el blob o para renovar, cambiar o liberar la concesión.

Una operación renew correcta también devuelve el identificador de concesión para la concesión activa.
x-ms-lease-time: seconds Tiempo restante aproximado del período de concesión, en segundos. Este encabezado solo se devuelve para una solicitud correcta de interrupción de la concesión. Si la interrupción es inmediata, 0 se devuelve.
x-ms-request-id Este encabezado identifica de forma única la solicitud que se realizó y se puede usar para solucionar problemas de la solicitud. Para más información, consulte Solución de problemas de operaciones de API.
x-ms-version Indica la versión de Blob Storage usada para ejecutar la solicitud. Este encabezado se devuelve para las solicitudes realizadas en la versión 2009-09-19 y versiones posteriores.
Date Valor de fecha y hora UTC que indica la hora a la que se inició la respuesta. El servicio genera este valor.
Access-Control-Allow-Origin Se devuelve si la solicitud incluye un Origin encabezado y CORS está habilitado con una regla coincidente. Este encabezado devuelve el valor del encabezado Origin de la solicitud en caso de que haya una coincidencia.
Access-Control-Expose-Headers Se devuelve si la solicitud incluye un Origin encabezado y CORS está habilitado con una regla coincidente. Devuelve la lista de encabezados de respuesta que se van a exponer al cliente o el emisor de la solicitud.
Access-Control-Allow-Credentials Se devuelve si la solicitud incluye un Origin encabezado y CORS está habilitado con una regla coincidente que no permite todos los orígenes. Este encabezado se establece en true.
x-ms-client-request-id Puede usar este encabezado para solucionar problemas de solicitudes y respuestas correspondientes. El valor de este encabezado es igual al valor del x-ms-client-request-id encabezado, si está presente en la solicitud. El valor tiene como máximo 1024 caracteres ASCII visibles. Si el x-ms-client-request-id encabezado no está presente en la solicitud, no estará presente en la respuesta.

Response body

Ninguno.

Respuesta de muestra

A continuación se muestra una respuesta de ejemplo para una solicitud de adquisición de una concesión:

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
Date: <date>  
  

Authorization

Se requiere autorización al llamar a cualquier operación de acceso a datos en Azure Storage. Puede autorizar la Lease Blob operación como se describe a continuación.

Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con Microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad. La entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada de Azure. La entidad de seguridad se autentica mediante Microsoft Entra ID para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.

Para más información sobre la autorización mediante Microsoft Entra ID, consulte Autorización del acceso a blobs mediante Microsoft Entra ID.

Permisos

A continuación se enumeran las acciones de RBAC necesarias para un usuario, grupo o entidad de servicio de Microsoft Entra para llamar a la Lease Blob operación y el rol RBAC integrado con privilegios mínimos que incluye esta acción:

Para más información sobre la asignación de roles mediante RBAC de Azure, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

Comentarios

Una concesión sobre un blob proporciona acceso exclusivo de escritura y eliminación sobre el blob. Para escribir en un blob con una concesión activa, un cliente debe incluir el identificador de la concesión activa en la solicitud de escritura. La concesión se concede durante el tiempo especificado cuando se adquiere la concesión. Esta duración puede estar entre 15 y 60 segundos o una duración infinita.

Cuando un cliente adquiere una concesión, se devuelve un identificador de concesión. Blob Storage genera un identificador de concesión si no se especifica uno en la solicitud de adquisición. El cliente puede usar este identificador de concesión para renovar la concesión, cambiar su identificador de concesión o liberar la concesión.

Cuando una concesión está activa, se debe incluir el identificador de concesión en la solicitud para cualquiera de las operaciones siguientes:

Si no se incluye el identificador de concesión, estas operaciones producirán un error en un blob concedido, con 412 – Precondition failed.

Las siguientes operaciones se realizan correctamente en un blob alquilado, sin incluir el identificador de concesión:

No es necesario incluir el identificador de concesión para GET las operaciones en un blob que tenga una concesión activa. Sin embargo, todas las GET operaciones admiten un parámetro de concesión condicional, donde la operación solo continúa si el identificador de concesión incluido con la solicitud es válido.

Se admiten todas las operaciones de contenedor en un contenedor que incluye blobs con una concesión activa, como Delete Container. Por lo tanto, se puede eliminar un contenedor incluso si los blobs que contiene tienen concesiones activas. Utilice la operación Lease Container para controlar los derechos para eliminar un contenedor.

Estados de concesión

En el diagrama siguiente se muestran los cinco estados de una concesión y los comandos o los eventos que provocan cambios en el estado de la misma.

Diagrama que muestra los estados de concesión de blobs y los desencadenadores de cambio de estado.

Una concesión puede estar en uno de estos estados, en función de si la concesión está bloqueada o desbloqueada, y si la concesión es renovable en ese estado. Las acciones de concesión que se muestran en el diagrama anterior provocan transiciones de estado.

Estado de renovación Concesión bloqueada Concesión desbloqueada
Concesión renovable Leased Expirada
Concesión no renovable Problemático Broken, Available
  • Available: la concesión está desbloqueada y se puede adquirir. Acción permitida: acquire.

  • Leased: la concesión está bloqueada. Acciones permitidas: acquire (solo con el mismo identificador de concesión), renew, change, release y break.

  • Expired: la duración de la concesión ha expirado. Acciones permitidas: acquire, renew, release y break.

  • Breaking: la concesión se ha interrumpido, pero la concesión seguirá bloqueada hasta que haya expirado el período de interrupción. Acciones permitidas: release y break.

  • Broken: la concesión se ha interrumpido y el período de interrupción ha expirado. Acciones permitidas: acquire, release y break.

Una vez que una concesión ha expirado, Blob Storage mantiene el identificador de concesión hasta que el blob se modifica o se concede de nuevo. Un cliente puede intentar renovar o liberar la concesión mediante su identificador de concesión expirado. Si la operación se realiza correctamente, significa que el blob no se ha cambiado desde que el identificador de concesión era válido por última vez.

Si el cliente intenta renovar o liberar una concesión con su identificador de concesión anterior y se produce un error en la solicitud, el blob se modificó o se arrendó de nuevo desde que la concesión del cliente estaba activa por última vez. En ese caso, el cliente deberá adquirir una nueva concesión sobre el blob.

Si una concesión expira en lugar de publicarse explícitamente, es posible que un cliente tenga que esperar hasta un minuto antes de que se pueda adquirir una nueva concesión para el blob. Sin embargo, el cliente puede renovar la concesión con su identificador de concesión inmediatamente, si el blob no se ha modificado.

Tenga en cuenta que no se puede conceder una concesión para una instantánea de blob, ya que las instantáneas son de solo lectura. Si se solicita una concesión sobre una instantánea, se obtiene el código de estado 400 (Solicitud incorrecta).

La propiedad del Last-Modified-Time blob no se actualiza mediante llamadas a Lease Blob.

En las tablas siguientes se muestran los resultados de realizar distintas acciones sobre blobs con concesiones en distintos estados de concesión. Las letras (A), (B) y (C) representan identificadores de concesión y (X) representan un identificador de concesión generado por Blob Storage.

Resultados de los intentos de utilizar blobs según su estado de concesión

Acción Disponible Leased (A) Breaking (A) Broken (A) Expired (A)
Escribir con (A) Error (412) Leased (A), la escritura se realiza correctamente Breaking (A), la escritura se realiza correctamente Error (412) Error (412)
Escribir con (B) Error (412) Error (409) Error (412) Error (412) Error (412)
Escribir sin especificar la concesión Available, la escritura se realiza correctamente Error (412) Error (412) Available, la escritura se realiza correctamente Available, la escritura se realiza correctamente
Leer con (A) Error (412) Leased (A), la lectura se realiza correctamente Breaking (A), la lectura se realiza correctamente Error (412) Error (412)
Leer con (B) Error (412) Error (409) Error (409) Error (412) Error (412)
Leer sin especificar la concesión Available, la lectura se realiza correctamente Leased (A), la lectura se realiza correctamente Breaking (A), la lectura se realiza correctamente Broken (A), la lectura se realiza correctamente Expired (A), la lectura se realiza correctamente

Resultados de las operaciones de concesión sobre los blobs según su estado de concesión

Acción Disponible Leased (A) Breaking (A) Broken (A) Expired (A)
Acquire sin identificador de concesión propuesto Leased (X) Error (409) Error (409) Leased (X) Leased (X)
Acquire (A) Leased (A) Leased (A), nueva duración Error (409) Leased (A) Leased (A)
Acquire (B) Leased (B) Error (409) Error (409) Leased (B) Leased (B)
Break, período=0 Error (409) Broken (A) Broken (A) Broken (A) Broken (A)
Break, período>0 Error (409) Breaking (A) Breaking (A) Broken (A) Broken (A)
Change, (A) a (B) Error (409) Leased (B) Error (409) Error (409) Error (409)
Change, (B) a (A) Error (409) Leased (A) Error (409) Error (409) Error (409)
Change, (B) a (C) Error (409) Error (409) Error (409) Error (409) Error (409)
Renew (A) Error (409) Leased (A), reloj de caducidad restablecido Error (409) Error (409) Leased(A), si el blob no se ha modificado.

Error (409) si se ha modificado el blob.
Renew (B) Error (409) Error (409) Error (409) Error (409) Error (409)
Release (A) Error (409) Disponible Disponible Disponible Disponible
Release (B) Error (409) Error (409) Error (409) Error (409) Error (409)
La duración expira Disponible Expired (A) Broken (A) Broken (A) Expired (A)

Cambios en el blob de concesión introducidos en la versión 2012-02-12

En la lista siguiente se especifican los cambios en el Lease Blob comportamiento introducidos en la versión 2012-02-12.

  • Una llamada a para Lease Blob adquirir una concesión ahora debe incluir un encabezado de duración de concesión. Si intenta adquirir una concesión sin especificar una duración de concesión, el servicio devuelve 400 Bad Request – Missing required header.

  • Ya no se puede renovar una concesión después de liberarla. Si intenta hacerlo, el servicio devuelve 409 Conflict – The lease ID specified did not match the lease ID for the blob. Las aplicaciones que llamaron a release y, a continuación, llamaron a renew, deben guardar ahora el ETag elemento de la llamada de versión. A continuación, las aplicaciones deben llamar a acquire, con un If-Match encabezado condicional, para adquirir la concesión solo cuando el blob no cambia.

  • Ya no se puede interrumpir una concesión después de liberarla. Si intenta hacerlo, el servicio devuelve 409 Conflict – There is currently no lease on the blob.

  • Ahora es posible interrumpir una concesión que se está interrumpiendo o que está interrumpida, lo que hace que las operaciones de interrupción se conviertan en idempotentes. En versiones anteriores, esto provocaba el error 409 Conflict – The lease has already been broken and cannot be broken again. Este cambio permite acortar la duración de una interrupción. Si interrumpe una concesión que se encuentra en estado de interrupción e incluye una duración más corta que el período de interrupción restante, se usa la duración más corta.

Facturación

Las solicitudes de precios pueden originarse en clientes que usan API de Blob Storage, ya sea directamente a través de la API REST de Blob Storage o desde una biblioteca cliente de Azure Storage. Estas solicitudes acumulan cargos por transacción. El tipo de transacción afecta a cómo se cobra la cuenta. Por ejemplo, las transacciones de lectura se acumulan en una categoría de facturación diferente a las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de Lease Blob las solicitudes basadas en el tipo de cuenta de almacenamiento:

Operación Tipo de cuenta de almacenamiento Categoría de facturación
Blob de concesión (adquirir, liberar, renovar) Blobs en bloques Premium
De uso general, estándar, v2
Otras operaciones
Blob de concesión (adquirir, liberar, renovar) De uso general, estándar, v1 Lee operaciones.
Blob de concesión (interrupción, cambio) Blobs en bloques Premium
De uso general, estándar, v2
Otras operaciones
Blob de concesión (interrupción, cambio) De uso general, estándar, v1 Operaciones de escritura

Consulte también

new-blob-lease-features-infinite-leases-smaller-lease-times-and-more.aspx)
Autorización de solicitudes a Azure Storage
Estado y códigos de error
Códigos de error de Blob Storage
Lease Container