Put Block List

Artículo
02/12/2024

La operación Put Block List escribe un blob especificando la lista de identificadores de bloque que conforman el blob. Para escribirse como parte de un blob, un bloque debe haberse escrito correctamente en el servidor en una operación Put Block anterior.

Para llamar a para actualizar Put Block List un blob, cargue solo los bloques que han cambiado y, a continuación, confirme los bloques nuevos y existentes juntos. Puede hacerlo especificando si se debe confirmar un bloque de la lista de bloqueos confirmados o de la lista de bloqueos no confirmados, o para confirmar la versión cargada más recientemente del bloque, a la lista a la que pertenece.

Solicitud

Puede construir la solicitud de la Put Block List siguiente manera. Se recomienda usar 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=blocklist`	HTTP/1.1

Solicitud del servicio de almacenamiento emulado

Cuando realice una solicitud en el servicio de almacenamiento emulado, especifique el nombre de host del emulador y el puerto de Blob Service 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 solo admite tamaños de blob de hasta 2 gibibytes (GiB).

Para más información, consulte Uso del emulador de Azurite para desarrollo y pruebas locales de Azure Storage.

Parámetros del identificador URI

Puedes especificar los siguientes parámetros adicionales en el URI de la solicitud:

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

Encabezados de solicitud

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

Encabezado de solicitud	Descripción
`Authorization`	Necesario. Especifica el esquema de autorización, el nombre de 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`	Necesario para todas las solicitudes autorizadas. 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.
`Content-Length`	Necesario. Longitud del contenido de la solicitud, en bytes. Este encabezado hace referencia a la longitud de contenido de la lista de bloques, no al propio blob.
`Content-MD5`	Opcional. Hash MD5 del contenido de la solicitud. Este hash se utiliza 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 solicitud y no al contenido del propio blob.
`x-ms-content-crc64`	Opcional. Hash CRC64 del contenido de la solicitud. Este hash se utiliza 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 solicitud y no al contenido del propio blob. Si los encabezados Content-MD5 y x-ms-content-crc64 están presentes, la solicitud produce un error 400 (solicitud incorrecta). Este encabezado es compatible con la versión 2019-02-02 y posteriores.
`x-ms-blob-cache-control`	Opcional. Establece el control de caché del blob. Si se especifica esta propiedad, se almacena con el blob y se devuelve con una solicitud de lectura. Si la propiedad no se especifica con la solicitud, se borra para el blob si la solicitud se realiza correctamente.
`x-ms-blob-content-type`	Opcional. Establece el tipo de contenido del blob. Si se especifica, esta propiedad se almacena con el blob y se devuelve con una solicitud de lectura. Si no se especifica el tipo de contenido, se establece en el tipo predeterminado, que es `application/octet-stream`.
`x-ms-blob-content-encoding`	Opcional. Establece la codificación del contenido del blob. Si se especifica, esta propiedad se almacena con el blob y se devuelve con una solicitud de lectura. Si la propiedad no se especifica con la solicitud, se borra para el blob si la solicitud se realiza correctamente.
`x-ms-blob-content-language`	Opcional. Establece el idioma de contenido del blob. Si se especifica, esta propiedad se almacena con el blob y se devuelve con una solicitud de lectura. Si la propiedad no se especifica con la solicitud, se borra para el blob si la solicitud se realiza correctamente.
`x-ms-blob-content-md5`	Opcional. Hash MD5 del contenido del blob. Este hash no se valida, ya que los hashes de los bloques individuales se validaron cuando se cargó cada uno. La operación Obtener blob devuelve el valor de este encabezado en el encabezado de respuesta Content-MD5. Si esta propiedad no se especifica con la solicitud, se borra para el blob si la solicitud se realiza correctamente.
`x-ms-meta-name:value`	Opcional. Pares de 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 las reglas de nomenclatura para los identificadores de C#.
`x-ms-encryption-scope`	Opcional. Indica el ámbito de cifrado que se va a usar para cifrar el blob. Este valor debe coincidir con el ámbito de cifrado que se usa para cifrar todos los bloques que se están confirmando. Este encabezado es compatible con la versión 2019-02-02 y posteriores.
`x-ms-encryption-context`	Opcional. El valor predeterminado es "Empty". Si el valor se establece, establecerá los metadatos del sistema de blobs. Longitud máxima-1024. Válido solo cuando el espacio de nombres jerárquico está habilitado para la cuenta. Este encabezado se admite en las versiones 2021-08-06 y posteriores.
`x-ms-tags`	Opcional. Establece las etiquetas codificadas de cadena de consulta especificadas en el blob. Para obtener más información, vea la sección Comentarios . 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 de 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 de análisis 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. Establece el encabezado `Content-Disposition` del blob. Disponible para la versión 2013-08-15 y posteriores. El `Content-Disposition` campo de encabezado transmite información adicional sobre cómo procesar la carga de respuesta y se puede usar para adjuntar metadatos adicionales. Por ejemplo, si se establece `attachment`en , este encabezado indica que el agente de usuario no debe mostrar la respuesta, sino que debería mostrar un cuadro de diálogo Guardar como. La respuesta de las operaciones Get Blob y Get Blob Properties incluye el encabezado content-disposition.
`x-ms-access-tier`	Opcional. Versión 2018-11-09 y posteriores. Indica el nivel que se va a establecer en un blob. En el caso de los blobs en bloques, este encabezado se admite en cuentas de almacenamiento de blobs o de uso general v2 solo con la versión 2018-11-09 y versiones posteriores. Los valores válidos para los niveles de blob en bloques son `Hot`, `Cool`, `Cold`y `Archive`. Nota: `Cold` el nivel es compatible con la versión 2021-12-02 y posteriores. Para obtener información detallada sobre la creación de niveles de blobs en bloques, consulte Niveles de almacenamiento de acceso frecuente, esporádico y de archivo.
`x-ms-immutability-policy-until-date`	Versión 2020-06-12 y posteriores. Especifica la fecha de retención hasta que se va a establecer en el blob. Esta es la fecha hasta la que se puede proteger el blob de que se va a modificar o eliminar. Sigue RFC1123 formato.
`x-ms-immutability-policy-mode`	Versión 2020-06-12 y posteriores. Especifica el modo de directiva de inmutabilidad que se va a establecer en el blob. Los valores válidos son `unlocked` y `locked`. El `unlocked` valor indica que los usuarios pueden cambiar la directiva aumentando o disminuyendo la fecha de retención hasta la fecha. El `locked` valor indica que estas acciones están prohibidas.
`x-ms-legal-hold`	Versión 2020-06-12 y posteriores. Especifica la suspensión legal que se va a 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 expiración de la solicitud, consulte ExpiryOption. Este encabezado es válido para las cuentas con el espacio de nombres jerárquico habilitado.
`x-ms-expiry-time`	Opcional. Versión 2023-08-03 y posteriores. Especifica la hora en que el blob está establecido para expirar. El formato de la fecha de expiración varía según `x-ms-expiry-option`. Para obtener más información, consulte ExpiryOption. Este encabezado es válido para las cuentas con el espacio de nombres jerárquico habilitado. El `expiryTime` elemento que ya está presente en un blob no se borra si la solicitud no contiene un nuevo valor de `expiryTime`

Esta operación también admite el uso de encabezados condicionales para confirmar la lista de bloqueo 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.

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

A partir de la versión 2019-02-02, puede 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.

Encabezado de solicitud	Descripción
`x-ms-encryption-key`	Necesario. La clave de cifrado AES-256 codificada en Base64.
`x-ms-encryption-key-sha256`	Necesario. Hash SHA256 codificado en Base64 de la clave de cifrado.
`x-ms-encryption-algorithm: AES256`	Necesario. 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, puede especificar la lista de bloques que Blob Storage debe comprobar para el bloque solicitado. De este modo, puede actualizar un blob existente insertando, reemplazando o eliminando bloques individuales, en lugar de volver a cargar todo el blob. Después de cargar el bloque o bloques que han cambiado, puede confirmar una nueva versión del blob confirmando los nuevos bloques junto con los bloques existentes que desea conservar.

Para actualizar un blob, puede especificar que el servicio debe buscar un identificador de bloque en la lista de bloques confirmados, en la lista de bloques sin confirmar, o primero en la lista de bloques sin confirmar y después en la lista de bloques confirmados. Para indicar qué enfoque usar, especifique el identificador de bloque que se encuentra dentro del elemento XML adecuado dentro del cuerpo de la solicitud, como se indica a continuación:

Especifique el identificador de bloque dentro del Committed elemento para indicar que Blob Storage debe buscar solo la lista de bloques confirmada para el bloque con nombre. Si el bloque no se encuentra en la lista de bloques confirmados, no se escribe como parte del blob y Blob Storage devuelve el código de estado 400 (solicitud incorrecta).
Especifique el identificador de bloque dentro del Uncommitted elemento para indicar que Blob Storage debe buscar solo la lista de bloques sin confirmar para el bloque con nombre. Si el bloque no se encuentra en la lista de bloques sin confirmar, no se escribe como parte del blob y Blob Storage devuelve el código de estado 400 (solicitud incorrecta).
Especifique el identificador de bloque dentro del Latest elemento para indicar que Blob Storage debe buscar primero en la lista de bloques sin confirmar. Si el bloque se encuentra en la lista de bloques sin confirmar, esa versión del bloque es la más reciente y se debe escribir en el blob. Si el bloque no se encuentra en la lista no confirmada, el servicio debe buscar en la lista de bloques confirmada el bloque con nombre y escribir ese bloque en el blob si se encuentra.

El cuerpo de la solicitud para esta versión de Put Block List usa 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 demostrar Put Block List, supongamos que ha cargado tres bloques que ahora desea confirmar. En el siguiente ejemplo se confirma un nuevo blob indicando que debe utilizarse la versión más reciente de cada bloque de la lista. No es necesario saber si estos bloques ya se han confirmado.

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 quiere actualizar el blob. El nuevo blob tiene los siguientes cambios:

Un nuevo bloque con el identificador ANAAAA==. Este bloque debe cargarse primero con una llamada a Put Block y aparece en la lista de bloqueos sin confirmar hasta que la llamada a Put Block List.
Una versión actualizada del bloque con el identificador AZAAAA==. Este bloque debe cargarse primero con una llamada a Put Block y aparece en la lista de bloqueos sin confirmar hasta que la llamada a Put Block List.
Eliminación del bloque con el identificador AAAAAA==. Dado que este bloque no se incluye en la siguiente llamada a Put Block List, el bloque se quita eficazmente del blob.

En el ejemplo siguiente se 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>

Response

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

status code

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

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

Encabezados de respuesta

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

Response	Descripciones
`ETag`	La etiqueta de entidad contiene un valor que el cliente puede usar para realizar operaciones `GET/PUT` condicionales mediante el encabezado de solicitud `If-Match`. Si la versión de la solicitud es 2011-08-18 o posterior, el valor ETag se incluye entre comillas.
`Last-Modified`	La fecha y la hora en la que se modificó por última vez el blob. El formato de la fecha sigue las convenciones de 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 hace referencia al contenido de la solicitud (en este caso, la lista de bloques y no el contenido del propio blob). Para la versión 2019-02-02 y posteriores, este encabezado solo se devuelve cuando la solicitud tiene este encabezado.
`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 hace referencia al contenido de la solicitud (en este caso, la lista de bloques y no el contenido del propio blob). 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 más información, consulte Solución de problemas de operaciones de API.
`x-ms-version`	Versión de Blob Storage que se usa para ejecutar la solicitud. Este encabezado se devuelve para las solicitudes realizadas en la versión 2009-09-19 y posteriores.
`Date`	Valor de fecha y 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 este encabezado se establece `true` en si el contenido de la solicitud se cifra correctamente mediante 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 usó una clave proporcionada por el cliente para el cifrado, por lo que el cliente puede asegurarse de que el contenido de la solicitud se cifre correctamente mediante la clave proporcionada.
`x-ms-encryption-scope`	Versión 2019-02-02 y posteriores. Este encabezado se devuelve si la solicitud usó un ámbito de cifrado, por lo que el cliente puede asegurarse de que el contenido de la solicitud se cifre correctamente mediante el ámbito de cifrado.
`x-ms-version-id: <DateTime>`	Versión 2019-12-12 y posteriores. Devuelve un valor opaco `DateTime` que identifica de forma única el blob. El valor de este encabezado indica la versión del blob y se puede usar 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 `x-ms-client-request-id` encabezado si está presente en la solicitud y el valor no contiene más de 1024 caracteres ASCII visibles. Si el `x-ms-client-request-id` encabezado no está presente en la solicitud, no está presente en la respuesta.

Respuesta de muestra

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 Put Block List operación como se describe a continuación.

Si una solicitud especifica etiquetas con el encabezado de x-ms-tags solicitud, el autor de la llamada debe cumplir los requisitos de autorización de la operación Establecer etiquetas de blob .

Importante

Microsoft recomienda usar Microsoft Entra ID con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso 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. 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, identidad administrada o entidad de servicio de Microsoft Entra para llamar a la Put Block List operación y el rol RBAC integrado con privilegios mínimos que incluye esta acción:

Acción RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rol integrado con privilegios mínimos:Colaborador de datos de Storage Blob

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.

Una firma de acceso compartido (SAS) proporciona acceso delegado seguro a los recursos de una cuenta de almacenamiento. Con una SAS, tiene un control granular sobre cómo un cliente puede acceder a los datos. Puede especificar a qué recurso puede tener acceso el cliente, a qué permisos tienen esos recursos y cuánto tiempo es válido la SAS.

La Put Block List operación admite tres tipos de firmas de acceso compartido: SAS de delegación de usuarios, SAS de servicio y SAS de cuenta.

Como procedimiento recomendado de seguridad, se recomienda usar Microsoft Entra credenciales en lugar de la clave de la cuenta de almacenamiento, lo que se puede poner en peligro más fácilmente. Si el diseño de la aplicación requiere firmas de acceso compartido, use Microsoft Entra credenciales para crear una SAS de delegación de usuarios, siempre que sea posible.

Cuando no se permite el acceso a la clave compartida para la cuenta de almacenamiento, no se permitirá un token de SAS de servicio o un token de SAS de cuenta en una solicitud a Blob Storage. Para más información, consulte Descripción de cómo no permitir la clave compartida afecta a los tokens de SAS.

SAS de delegación de usuarios

Una SAS de delegación de usuarios se protege con credenciales de Microsoft Entra y también con los permisos especificados para la SAS.

Llamar a la Put Block List operación mediante un token de SAS delegado en un contenedor o recurso de blob requiere el permiso De escritura (w) como parte del token de SAS de delegación de usuarios.

Para más información sobre la SAS de delegación de usuarios, consulte Create una SAS de delegación de usuarios.

SAS de servicio

Una SAS de servicio está protegida con la clave de cuenta de almacenamiento. Una SAS de servicio delega el acceso a un recurso en un único servicio de Azure Storage, como Blob Storage.

Llamar a la Put Block List operación mediante un token de SAS delegado en un contenedor o recurso de blob requiere el permiso De escritura (w) como parte del token de SAS de servicio.

Para más información sobre la SAS de servicio, consulte Create una SAS de servicio.

SAS de cuenta

Una SAS de cuenta está protegida con la clave de cuenta de almacenamiento. SAS de cuenta delega el acceso a los recursos en uno o varios de los servicios de almacenamiento. Todas las operaciones disponibles con una SAS de servicio o delegación de usuarios están también disponibles con una SAS de cuenta.

En la tabla siguiente se indica el tipo de recurso firmado y los permisos firmados que se deben especificar al delegar el acceso:

Operación	Servicio firmado	Tipo de recurso firmado	Permiso firmado
Put Block List	Blob (b)	Objeto (o)	Escritura (w)

Para más información sobre la SAS de la cuenta, consulte Create una SAS de cuenta.

Comentarios

La operación Put Block List determina el orden en que se deben combinar los bloques para crear un blob.

Se puede especificar el mismo identificador de bloque más de una vez en la lista de bloques. Si se especifica un identificador de bloque más de una vez, representa el intervalo de bytes en cada una de esas ubicaciones de la lista de bloques para el blob confirmado final. Si un identificador de bloque aparece más de una vez en la lista, se deben especificar ambas instancias del identificador del bloque en la misma lista de bloqueados. Es decir, ambas instancias deben especificarse en el elemento Committed, el elemento Uncommitted o elemento Latest.

Con Put Block List, puede modificar un blob existente insertando, actualizando o eliminando bloques individuales sin tener que volver a cargar el blob completo. Puede especificar identificadores de bloque de la lista actual de bloques confirmados y de la lista de bloques sin confirmar para crear un nuevo blob o actualizar el contenido de un blob existente. De este modo, puede actualizar un blob especificando algunos bloques nuevos de la lista de bloques sin confirmar y el resto de la lista de bloques confirmada, que ya forman parte del blob existente.

Si se especifica un identificador de bloque en el elemento Latest y el mismo identificador de bloque existe en las listas de bloques confirmados y sin confirmar, Put Block List confirma el bloque de la lista de bloques sin confirmar. Si el identificador de bloque existe en la lista de bloqueados confirmados, pero no en la lista de bloqueados sin confirmar, Put Block List confirma el bloque de la lista de bloqueados confirmados.

Cada bloque de un blob en bloques puede tener un tamaño diferente. Un blob en bloques puede incluir un máximo de 50 000 bloques confirmados. El número máximo de bloques no confirmados que se pueden asociar a un blob es de 100 000.

En la tabla siguiente se describen los tamaños máximos permitidos de bloques y blobs, por versión del servicio:

Versión del servicio	Tamaño máximo de bloque (a través de `Put Block`)	Tamaño máximo del blob (a través de `Put Block List`)	Tamaño máximo de blob a través de una operación de escritura única (a través de `Put Blob`)
Versión 2019-12-12 y posteriores	4000 mebibytes (MiB)	Aproximadamente 190,7 tebibytes (TiB) (4000 MiB × 50 000 bloques)	5000 MiB
Versiones 2016-05-31 a 2019-07-07	100 MiB	Aproximadamente 4,75 TiB (100 MiB × 50 000 bloques)	256 MiB
Versiones anteriores a 2016-05-31	4 MiB	Aproximadamente 195 GiB (4 MiB × 50 000 bloques)	64 MiB

Cuando se llama a Put Block List para actualizar un blob existente, se sobrescriben las propiedades y los metadatos existentes del blob. Sin embargo, cualquier instantánea existente se conserva con el blob. Puede utilizar los encabezados de solicitud condicionales si desea que solo se realice la operación si se cumple una condición especificada.

Si se produce un error en la Put Block List operación debido a un bloque que falta, debe cargar el bloque que falta.

Los bloques no confirmados se recopilan como elementos no utilizados si no hay llamadas correctas a Put Block o Put Block List en el blob en una semana después de la última operación correcta Put Block . Si se llama a Put Blob en el blob, los bloques no confirmados se recopilan como elementos no utilizados.

Si se proporcionan etiquetas en el x-ms-tags encabezado, deben estar codificadas en cadena de consulta. Las claves y los valores de etiqueta deben cumplir los requisitos de nomenclatura y longitud, 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, use la operación Establecer etiquetas de blob .

Si el blob tiene una concesión activa, el cliente debe especificar un identificador de concesión válido en la solicitud para confirmar la lista de bloques. 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 identificador de concesión, pero el blob no tiene una concesión activa, Blob Storage también devuelve el código de estado 412 (error de condición previa). Si el cliente especifica un identificador de concesión en un blob que aún no existe, Blob Storage devuelve el código de estado 412 (error de condición previa) para las solicitudes realizadas en 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 una concesión activa y se llama a Put Block List para actualizar el blob, la concesión se mantiene en el blob actualizado.

Put Block List se aplica solo a los blobs en bloques. Si llama a Put Block List en un blob en páginas, se generará el código de estado 400 (Solicitud incorrecta).

Se produce un error al sobrescribir un blob archivado y sobrescribir un hot blob o cool hereda el nivel del blob anterior si no se proporciona el encabezado x-ms-access-tier.

Facturación

Las solicitudes de precios se pueden originar en clientes que usan las API de Blob Storage, ya sea directamente a través de la API rest de Blob Storage o de 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 que las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de Put Block List las solicitudes basadas en el tipo de cuenta de almacenamiento:

Operación	Tipo de cuenta de almacenamiento	Categoría de facturación
Put Block List	Blobs en bloques Premium De uso general, estándar, v2 De 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 Azure Blob Storage.

Consulte también

Descripción de los blobs en bloques, los blobs en anexos y los blobs en páginas
Autorización de solicitudes a Azure Storage
Estado y códigos de error
Códigos de error de Blob service
Establecimiento de tiempos de espera para las operaciones de Blob Service

Compartir a través de