Compartir a través de

Poner lista de bloqueo

La Put Block List operación escribe un blob especificando la lista de IDs de bloque que componen el blob. Para que se escriba como parte de un blob, un bloque debe haber sido escrito correctamente en el servidor en una operación anterior de Put Block .

Puedes solicitar Put Block List actualizar un blob subiendo solo aquellos bloques que hayan cambiado y luego haciendo un commit entre los bloques nuevos y existentes. Puedes hacerlo especificando si comprometer un bloque de la lista de bloqueos comprometidos o de la lista no comprometida, o comprometer la versión más reciente del bloque, según la lista a la que pertenezca.

Solicitud

Puede construir la solicitud Put Block List de la siguiente manera. Se recomienda usar HTTPS. Sustituye myaccount por el nombre de tu cuenta de almacenamiento:

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

Solicitud de servicio de almacenamiento emulado

Cuando hagas una solicitud contra el servicio de almacenamiento emulado, especifica el nombre de host del emulador y el puerto del servicio Blob 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=blocklist HTTP/1.1

El emulador de almacenamiento soporta tamaños de blob de hasta 2 gibibytes (GiB) únicamente.

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

Parámetros de URI

Puede especificar los siguientes parámetros adicionales 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 Establecer tiempos de espera para operaciones de servicio Blob.

Encabezados de solicitud

Los encabezados de solicitud obligatorios y opcionales se describen en la tabla siguiente:

Cabecera de solicitud Descripción
Authorization Obligatorio. Especifica el esquema de autorización, el nombre de la cuenta y la firma. Para más información, consulte Autorizar solicitudes a Azure Storage.
Date o x-ms-date Obligatorio. Especifica la hora universal coordinada (UTC) de la solicitud. Para más información, consulte Autorizar solicitudes a Azure Storage.
x-ms-version Necesario para todas las solicitudes autorizadas. Especifica la versión de la operación que se va a usar para esta solicitud. Para más información, consulte Control de versiones de para los servicios de Azure Storage.
Content-Length Obligatorio. La longitud del contenido de la petición, en bytes. Este encabezado se refiere a la longitud del contenido de la lista de bloques, no al propio blob.
Content-MD5 Opcional. Hash MD5 del contenido de la solicitud. Este hash se usa para comprobar la integridad del contenido de la solicitud durante el transporte. Si ambos valores de hash no coinciden, la operación produce un error con el código de estado 400 (solicitud incorrecta).

Este encabezado está asociado al contenido de la petición, y no al contenido del blob en sí.
x-ms-content-crc64 Opcional. Un hash CRC64 del contenido de la solicitud. Este hash se usa para comprobar la integridad del contenido de la solicitud durante el transporte. Si ambos valores de hash no coinciden, la operación produce un error con el código de estado 400 (solicitud incorrecta).

Este encabezado está asociado al contenido de la petición, y no al contenido del blob en sí.

Si están presentes tanto los encabezados Content-MD5 como x-ms-content-crc64, la solicitud falla con un 400 (Mal Pedido).

Este encabezado se admite en la versión 2019-02-02 y posteriores.
x-ms-blob-cache-control Opcional. Establece el control de caché del blob. Si esta propiedad está especificada, se almacena con el blob y se devuelve con una solicitud de lectura.

Si la propiedad no se especifica con la solicitud, se limpia para el blob si la solicitud tiene éxito.
x-ms-blob-content-type Opcional. Establece el tipo de contenido del blob. Si está especificado, esta propiedad se almacena junto con el blob y se devuelve con una solicitud de lectura.

Si el tipo de contenido no está especificado, se establece al tipo por defecto, que es application/octet-stream.
x-ms-blob-content-encoding Opcional. Establece la codificación de contenido del blob. Si está especificado, esta propiedad se almacena junto con el blob y se devuelve con una solicitud de lectura.

Si la propiedad no se especifica con la solicitud, se limpia para el blob si la solicitud tiene éxito.
x-ms-blob-content-language Opcional. Establece el lenguaje de contenido del blob. Si está especificado, esta propiedad se almacena junto con el blob y se devuelve con una solicitud de lectura.

Si la propiedad no se especifica con la solicitud, se limpia para el blob si la solicitud tiene éxito.
x-ms-blob-content-md5 Opcional. Hash MD5 del contenido del blob. Este hash no se valida, porque los hashes de los bloques individuales se validaron cuando se subieron cada uno.

La operación Get Blob devuelve el valor de esta cabecera en la cabecera de respuesta Content-MD5.

Si esta propiedad no se especifica con la petición, se limpia para el blob si la solicitud tiene éxito.
x-ms-meta-name:value Opcional. Pares nombre-valor definidos por el usuario que están asociados al blob.

A partir de la versión 2009-09-19, los nombres de metadatos deben cumplir con las reglas de denominación para identificadores C#.
x-ms-encryption-scope Opcional. Indica el alcance de cifrado que se debe usar para cifrar el blob. Este valor debe coincidir con el alcance de cifrado que se utiliza para cifrar todos los bloques que se están comprometiendo. Este encabezado se admite en la versión 2019-02-02 y posteriores.
x-ms-encryption-context Opcional. El valor por defecto es "Vacío". Si el valor está establecido, se asignará los metadatos del sistema blob. Longitud máxima: 1024. Válido solo cuando el espacio de nombres jerárquico está habilitado para la cuenta. Este encabezado es compatible con las versiones 2021-08-06 y posteriores.
x-ms-tags Opcional. Establece las etiquetas codificadas en cadena de consulta especificadas en el blob. Para más información, consulte la sección de Observaciones . Compatible con la versión 2019-12-12 y posteriores.
x-ms-lease-id:<ID> Obligatorio si el blob tiene una concesión activa. Para realizar esta operación en un blob con una concesión activa, especifique el identificador de concesión válido para este encabezado.
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 analíticos cuando se configura el registro de análisis de almacenamiento. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes que recibe el servidor.
x-ms-blob-content-disposition Opcional. Coloca el encabezado de Content-Disposition la masa. Disponible para la versión 2013-08-15 y posteriores.

El Content-Disposition campo de cabecera proporciona información adicional sobre cómo procesar la carga útil de respuesta y puede utilizarse para adjuntar metadatos adicionales. Por ejemplo, si está configurado en attachment, este encabezado indica que el user-agent no debe mostrar la respuesta, sino que debe mostrar un cuadro de diálogo Guardar como.

La respuesta de las operaciones Get Blob y Get Blob Properties incluye el encabezado content-disposition (content-disposition disorder).
x-ms-access-tier Opcional. Versión 2018-11-09 y posteriores. Indica el nivel que se debe establecer en un blob. Para blobs de bloque, este encabezado es compatible con almacenamiento de blobs o cuentas de uso general v2 solo a partir de la versión 2018-11-09. Los valores válidos para los niveles de blob de bloques son , , , y ArchiveSmart . ColdCoolHot
Nota:Cold nivel es compatible con la versión 2021-12-02 y posteriores. Smart El nivel está soportado para la versión 2026-02-06 y posteriores, y actualmente está en vista previa pública.
Para información detallada sobre la tinajación de bloques de blobs, véase Niveles de almacenamiento de blobs.
x-ms-immutability-policy-until-date Versión 2020-06-12 y posteriores. Especifica la fecha de retención que se establecerá en el blob. Esta es la fecha hasta la que se puede proteger el blob para que no se modifique o elimine. Sigue RFC1123 formato.
x-ms-immutability-policy-mode Versión 2020-06-12 y posteriores. Especifica el modo de política de inmutabilidad que se debe establecer en el blob. Los valores válidos son unlocked y locked. El unlocked valor indica que los usuarios pueden cambiar la política aumentando o disminuyendo la fecha de retención hasta la fecha límite. El locked valor indica que estas acciones están prohibidas.
x-ms-legal-hold Versión 2020-06-12 y posteriores. Especifica la retención legal que se debe establecer en el blob. Los valores válidos son true y false.
x-ms-expiry-option Opcional. Versión 2023-08-03 y posteriores. Especifica la opción de fecha de vencimiento para la solicitud, véase VencimientoOpción. Este encabezado es válido para cuentas con espacio de nombres jerárquico habilitado.
x-ms-expiry-time Opcional. Versión 2023-08-03 y posteriores. Especifica la hora en la que el blob debe expirar. El formato de la fecha de caducidad varía según x-ms-expiry-option. Para más información, consulta VencimientoOpción. Este encabezado es válido para cuentas con espacio de nombres jerárquico habilitado.

El expiryTime que ya está presente en un blob no se borra si la petición no contiene un nuevo valor de expiryTime

Esta operación también permite el uso de encabezados condicionales para hacer commit en la lista de bloques solo si se cumple una condición especificada. Para obtener más información, consulte Especificar encabezados condicionales para las operaciones de Blob Storage.

Encabezados de solicitud (claves de cifrado proporcionadas por el cliente)

A partir de la versión 2019-02-02, puedes especificar los siguientes encabezados en la solicitud para cifrar un blob con una clave proporcionada por el cliente. El cifrado con una clave proporcionada por el cliente (y el conjunto de encabezados correspondiente) es opcional.

Cabecera de solicitud Descripción
x-ms-encryption-key Obligatorio. Clave de cifrado AES-256 codificada en Base64.
x-ms-encryption-key-sha256 Obligatorio. Hash SHA256 codificado en Base64 de la clave de cifrado.
x-ms-encryption-algorithm: AES256 Obligatorio. Especifica el algoritmo que se va a usar para el cifrado. El valor de este encabezado debe ser AES256.

Cuerpo de la solicitud

En el cuerpo de la solicitud, puedes especificar la lista de bloques que Blob Storage debe marcar para el bloque solicitado. De este modo, puedes actualizar un blob existente insertando, reemplazando o eliminando bloques individuales, en lugar de volver a subir todo el blob. Después de subir el bloque o bloques que han cambiado, puedes hacer commit para una nueva versión del blob commettant los nuevos bloques junto con los bloques existentes que quieres conservar.

Para actualizar un blob, puedes especificar que el servicio debe buscar un ID de bloque en la lista de bloqueos comprometidos, en la lista de bloqueos no comprometidos, o en la lista de bloqueos no comprometidos y luego en la lista de bloqueos comprometidos. Para indicar qué enfoque usar, especifica el ID de bloque que está dentro del elemento XML correspondiente dentro del cuerpo de la solicitud, de la siguiente manera:

  • Especifique el ID de bloque dentro del Committed elemento para indicar que Blob Storage debe buscar solo en la lista de bloques comprometida el bloque nombrado. Si el bloque no aparece en la lista de bloqueos comprometidos, no se escribe como parte del blob, y Blob Storage devuelve el código de estado 400 (Solicitud mala).

  • Especifica el ID de bloque dentro del Uncommitted elemento para indicar que Blob Storage debe buscar solo en la lista de bloques no comprometida el bloque nombrado. Si el bloque no aparece en la lista de bloqueos no comprometidos, no se escribe como parte del blob, y Blob Storage devuelve el código de estado 400 (Solicitud Incorrecta).

  • Especifique el ID de bloque dentro del Latest elemento para indicar que Blob Storage debe buscar primero en la lista de bloques no comprometida. Si el bloque se encuentra en la lista no comprometida, esa versión del bloque es la más reciente y debe escribirse en el blob. Si el bloque no aparece en la lista no comprometida, el servicio debería buscar en la lista de bloques comprometidos el bloque nombrado y escribir ese bloque en el blob si se encuentra.

El cuerpo de la solicitud para esta versión utiliza Put Block List el siguiente formato XML:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>

Solicitud de ejemplo

Para demostrarlo Put Block List, suponga que has subido tres bloques que ahora quieres comprometer. El siguiente ejemplo compromete un nuevo blob indicando que debe usarse la última versión de cada bloque listado. No es necesario saber si estos bloqueos ya se han cometido.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>

A continuación, supongamos que quieres actualizar el blob. El nuevo blob presenta los siguientes cambios:

  • Un bloque nuevo con DNI ANAAAA==. Este bloque debe subirse primero con una llamada a Poner Bloque, y aparece en la lista de bloqueos no comprometida hasta que la llamada a Put Block List.

  • Una versión actualizada del bloque con identificación AZAAAA==. Este bloque debe subirse primero con una llamada a Poner Bloque, y aparece en la lista de bloqueos no comprometida hasta que la llamada a Put Block List.

  • Eliminación del bloque con el DNI AAAAAA==. Como este bloque no se incluye en la siguiente llamada a Put Block List, el bloque queda efectivamente eliminado del blob.

El siguiente ejemplo muestra la llamada a Put Block List que actualiza el blob:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>

Respuesta

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

Código de estado

Una operación correcta devuelve el código de estado 201 (creado).

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

Encabezados de respuesta

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

Respuesta Descripciones
ETag La etiqueta de entidad contiene un valor que el cliente puede usar para realizar operaciones condicionales GET/PUT mediante el encabezado de la If-Match solicitud. Si la versión de la solicitud es 2011-08-18 o posterior, el valor de ETag se incluye entre comillas.
Last-Modified La fecha y hora en que se modificó por última vez el blob. El formato de fecha sigue a RFC 1123. Para obtener más información, vea Representar valores de fecha y hora en encabezados.

Cualquier operación que modifique el blob, incluida una actualización de los metadatos o las propiedades del blob, cambia la hora de la última modificación del blob.
Content-MD5 Se devuelve para que el cliente pueda comprobar la integridad del contenido del mensaje. Este encabezado se refiere al contenido de la solicitud (en este caso, a la lista de bloques y no al contenido del blob en sí). Para la versión 2019-02-02 y posteriores, este encabezado se devuelve solo cuando la solicitud lo tiene.
x-ms-content-crc64 Para la versión 2019-02-02 y posteriores, este encabezado se devuelve para que el cliente pueda comprobar la integridad del contenido del mensaje. Este encabezado se refiere al contenido de la solicitud (en este caso, a la lista de bloques y no al contenido del blob en sí).

Este encabezado se devuelve cuando Content-md5 el encabezado no está presente en la solicitud.
x-ms-request-id Identifica de forma única la solicitud que se realizó y puede usarla para solucionar problemas de la solicitud. Para obtener más información, consulte Solución de problemas de operaciones de API.
x-ms-version La versión de Blob Storage que se usa para ejecutar la solicitud. Este encabezado se devuelve para las solicitudes que se realizan en la versión 2009-09-19 y posteriores.
Date Un valor de fecha/hora UTC generado por el servicio, que indica cuándo se inició la respuesta.
x-ms-request-server-encrypted: true/false Versión 2015-12-11 y posteriores. El valor de esta cabecera se establece en true si el contenido de la solicitud se cifra con éxito usando el algoritmo especificado. De lo contrario, el valor se establece en false.
x-ms-encryption-key-sha256 Versión 2019-02-02 y posteriores. Este encabezado se devuelve si la solicitud ha utilizado una clave proporcionada por el cliente para el cifrado, de modo que el cliente pueda asegurarse de que el contenido de la solicitud se cifre correctamente usando la clave proporcionada.
x-ms-encryption-scope Versión 2019-02-02 y posteriores. Este encabezado se devuelve si la solicitud ha utilizado un alcance de cifrado, de modo que el cliente puede asegurarse de que el contenido de la solicitud está cifrado correctamente usando el ámbito de cifrado.
x-ms-version-id: <DateTime> Versión 2019-12-12 y posteriores. Devuelve un valor de DateTime opaco que identifica de forma única el blob. El valor de esta cabecera indica la versión del blob, y puede usarse en solicitudes posteriores para acceder al blob.
x-ms-client-request-id Se puede usar para solucionar problemas de solicitudes y sus respuestas correspondientes. El valor de este encabezado es igual al valor del encabezado x-ms-client-request-id si está presente en la solicitud y el valor no contiene más de 1024 caracteres ASCII visibles. Si el encabezado x-ms-client-request-id no está presente en la solicitud, no está presente en la respuesta.

Respuesta de ejemplo

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

Authorization

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

Si una solicitud especifica etiquetas con la x-ms-tags cabecera de la solicitud, el llamante debe cumplir los requisitos de autorización de la operación Set Blob Tags.

Importante

Microsoft recomienda usar el identificador de Entra de Microsoft con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona seguridad y facilidad de uso superiores en comparación con la autorización de clave compartida.

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. Microsoft Entra ID autentica la entidad de seguridad para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.

Para obtener más información sobre la autorización mediante el identificador de Entra de Microsoft, consulte Autorizar el acceso a blobs mediante el identificador de Microsoft Entra.

Permisos

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

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

Observaciones

La Put Block List operación impone el orden en que los bloques deben combinarse para crear un blob.

El mismo ID de bloque puede especificarse más de una vez en la lista de bloques. Si un ID de bloque se especifica más de una vez, representa el rango de bytes en cada una de esas ubicaciones en la lista de bloques para el blob final comprometido. Si un ID de bloque aparece más de una vez en la lista, ambas instancias del ID de bloque deben especificarse dentro de la misma lista de bloques. En otras palabras, ambas instancias deben especificarse dentro del Committed elemento, el Uncommitted elemento o el Latest elemento.

Con Put Block List, puedes modificar un blob existente insertando, actualizando o eliminando bloques individuales sin tener que subir todo el blob de nuevo. Puedes especificar IDs de bloque tanto de la lista de bloqueos de confirmados vigentes como de la lista de bloqueos no comprometidos para crear un nuevo blob o actualizar el contenido de un blob existente. De este modo, puedes actualizar un blob especificando algunos bloques nuevos de la lista de bloqueos no comprometidos y el resto de la lista de bloqueos comprometidos, que ya forman parte del blob existente.

Si se especifica un ID de bloque en el Latest elemento, y el mismo ID de bloque existe tanto en las listas de bloqueos comprometidas como en las no comprometidas, Put Block List se hace commit del bloque de la lista no comprometida. Si el ID de bloque existe en la lista de bloqueos comprometidos pero no en la lista no comprometida, Put Block List se hace commit al bloque de la lista de bloqueos comprometidos.

Cada bloque en un bloque puede tener un tamaño diferente. Un blob de bloques puede incluir un máximo de 50.000 bloques comprometidos. El número máximo de bloques no comprometidos que pueden asociarse a un blob es de 100.000.

La siguiente tabla describe los tamaños máximos permitidos de bloques y blobs, por versión del servicio:

Versión del servicio Tamaño máximo del bloque (vía Put Block) Tamaño máximo de la masa (vía Put Block List) Tamaño máximo del blob mediante una sola operación de escritura (vía Put Blob)
Versión 2019-12-12 y posteriores 4.000 mebibytes (MiB) Aproximadamente 190,7 tebibytes (TiB) (4.000 MiB × 50.000 bloques) 5.000 MiB
Versiones del 31-05-2016 al 07-07-2019 100 MiB Aproximadamente 4,75 TiB (100 MiB × 50.000 bloques) 256 MiB
Versiones anteriores al 31-05-2016 4 MiB Aproximadamente 195 GiB (4 MiB × 50.000 bloques) 64 MiB

Cuando llamas Put Block List para actualizar un blob existente, las propiedades y metadatos existentes del blob se sobrescriben. Sin embargo, cualquier instantánea existente se conserva con el blob. Puedes usar los encabezados de petición condicional para realizar la operación solo si se cumple una condición especificada.

Si la Put Block List operación falla por un bloque perdido, necesitas subir el bloque que falta.

Cualquier bloqueo no comprometido se recoge por la basura si no hay llamadas exitosas al Put Block blob o Put Block List sobre el blob en el plazo de una semana tras la última operación exitosa Put Block . Si se llama a Put Blob en el blob, los bloques no confirmados se recolectan como elementos no utilizados.

Si las etiquetas se proporcionan en la x-ms-tags cabecera, deben estar codificadas por cadena de consulta. Las claves y valores de etiquetas deben cumplir con los requisitos de nombre y longitud, tal como se especifica en Set Blob Tags. Además, el x-ms-tags encabezado puede contener etiquetas de hasta 2 KiB de tamaño. Si se requieren más etiquetas, utiliza la operación Set Blob Tags.

Si el blob tiene un arrendamiento activo, el cliente debe especificar un ID válido de arrendamiento en la solicitud para comprometer la lista de bloqueo. Si el cliente no especifica un identificador de concesión o especifica un identificador de concesión no válido, Blob Storage devuelve el código de estado 412 (error de condición previa). Si el cliente especifica un ID de arrendamiento pero el blob no tiene un arrendamiento activo, Blob Storage también devuelve el código de estado 412 (Precondición Fallida). Si el cliente especifica un ID de arrendamiento en un blob que aún no existe, Blob Storage devuelve el código de estado 412 (Precondición fallida) para solicitudes realizadas contra la versión 2013-08-15 o posterior. Para versiones anteriores, Blob Storage devuelve el código de estado 201 (Creado).

Si el blob tiene un contrato de arrendamiento activo y llamas Put Block List para actualizarlo, el arrendamiento se mantiene en el blob actualizado.

Put Block List Aplica solo a bloques de bloque. Llamar Put Block List a un blob de página da lugar al código de estado 400 (Solicitud Incorrecta).

Sobrescribir un archive blob falla. De lo contrario, un blob hereda el nivel del blob antiguo si no se proporciona un x-ms-access-tier encabezado.

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 las solicitudes de Put Block List en función del tipo de cuenta de almacenamiento:

Operación Tipo de cuenta de almacenamiento Categoría de facturación
Poner lista de bloqueo Blob en bloques Premium
Estándar de propósito general v2
Uso general estándar v1		 Operaciones de escritura

Para obtener información sobre los precios de la categoría de facturación especificada, consulte precios de Azure Blob Storage.

Consulte también

Entiende los bloques de bloques, los bloques de añadir y los bloques de página
Autorizar solicitudes a Azure Storage
códigos de error y estado
Códigos de error de servicio blob
Establecer tiempos de espera para las operaciones de servicio Blob

  • Last updated on