Put Block From URL

  • Artículo

La Put Block From URL operación crea un nuevo bloque que se confirmará como parte de un blob donde el contenido se lee desde una dirección URL. Esta API está disponible a partir de la versión 2018-03-28.

Solicitud

Puede construir la solicitud de la Put Block From URL 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=block&blockid=id 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=block&blockid=id HTTP/1.1

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

Parámetros del identificador URI

Parámetro Descripción
blockid Necesario. Valor de cadena de tipo Base64 válido que identifica el bloque. Para que se realice la codificación, el tamaño de la cadena debe ser menor o igual que 64 bytes.

Para un blob especificado, la longitud del valor especificado para el blockid parámetro debe tener el mismo tamaño para cada bloque.

Nota: La cadena Base64 debe estar codificada con dirección URL.
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. Para Put Block From URL, la versión debe ser 2018-03-28 o posterior.
Content-Length Necesario. Especifica el número de bytes que se transmiten en el cuerpo de la solicitud. El valor de este encabezado debe establecerse en 0. Cuando la longitud no es 0, se produce un error en la operación con el código de estado 400 (solicitud incorrecta).
x-ms-copy-source:name Necesario. Especifica la dirección URL del blob de origen. El valor puede ser una dirección URL de hasta 2 kibibytes (KiB) de longitud que especifica un blob. El valor debe estar codificado con dirección URL, ya que aparecería en un URI de solicitud. El blob de origen debe ser público o autorizado a través de una firma de acceso compartido. Si el blob de origen es público, no se requiere autorización para realizar la operación. Estos son algunos ejemplos de direcciones URL de objeto de origen:

- https://myaccount.blob.core.windows.net/mycontainer/myblob
- https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>
- https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>
x-ms-copy-source-authorization: <scheme> <signature> Opcional. Especifica el esquema de autorización y la firma del origen de copia. Para obtener más información, vea Autorización de solicitudes a Azure Storage.
Solo se admite un esquema de portador para Azure Active Directory.
Este encabezado se admite en las versiones 2020-10-02 y posteriores.
x-ms-source-range Opcional. Solo carga los bytes del blob en la dirección URL de origen del intervalo especificado. Si no se especifica este encabezado, todo el contenido del blob de origen se carga como un único bloque. Para más información, consulte Especificación del encabezado de intervalo para las operaciones de Blob Service.
x-ms-source-content-md5 Opcional. Hash MD5 del contenido del bloque del URI. Este hash se usa para comprobar la integridad del bloque durante el transporte de los datos desde el URI. Cuando se especifica este encabezado, el servicio de almacenamiento compara el hash del contenido que ha llegado del origen de copia con este valor de encabezado.

Nota: Este hash MD5 no se almacena con el blob.

Si ambos valores de hash no coinciden, la operación produce un error con el código de estado 400 (solicitud incorrecta).
x-ms-source-content-crc64 Opcional. Hash CRC64 del contenido del bloque del URI. Este hash se usa para comprobar la integridad del bloque durante el transporte de los datos desde el URI. Cuando se especifica este encabezado, el servicio de almacenamiento compara el hash del contenido que ha llegado del origen de copia con este valor de encabezado.

Nota: Este hash CRC64 no se almacena con el blob.

Si ambos valores de hash no coinciden, la operación produce un error con el código de estado 400 (solicitud incorrecta).

Si los x-ms-source-content-md5 encabezados y están x-ms-source-content-crc64 presentes, la solicitud produce un error 400 (solicitud incorrecta).

Este encabezado es compatible con las versiones 2019-02-02 y posteriores.
x-ms-encryption-scope Opcional. Indica el ámbito de cifrado que se va a usar para cifrar el contenido de origen. Este encabezado es compatible con las versiones 2019-02-02 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 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, consulte Supervisión de Azure Blob Storage.

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

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

Ninguno.

Solicitud de ejemplo

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

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, 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 otros encabezados HTTP estándar. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1.

Encabezado de respuesta Descripción
Content-MD5 Se devuelve para que el cliente pueda comprobar la integridad del contenido del mensaje. Blob Storage calcula el valor de este encabezado. No es necesariamente el mismo que el valor especificado en los encabezados de solicitud. Para las versiones 2019-02-02 y posteriores, este encabezado solo se devuelve cuando la solicitud tiene este encabezado.
x-ms-content-crc64 Para las versiones 2019-02-02 y posteriores. Se devuelve para que el cliente pueda comprobar la integridad del contenido del mensaje. Blob Storage calcula el valor de este encabezado. No es necesariamente el mismo que el valor especificado en los encabezados de solicitud.

Se devuelve cuando x-ms-source-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 usó para ejecutar la solicitud.
Date Valor de fecha y hora UTC generado por el servicio, que indica la hora a la que 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 del bloque 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. 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. 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-client-request-id Se puede usar 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 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 estará 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: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

Se requiere autorización al llamar a cualquier operación de acceso a datos en Azure Storage. Puede autorizar la Put Block From URL 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 Put Block From URL 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

Put Block From URL carga un bloque para su futura inclusión en un blob en bloques. Un blob en bloques puede incluir un máximo de 50 000 bloques. Cada bloque puede tener un tamaño diferente. El tamaño máximo de un bloque que se carga con Put Block From URL es de 100 mebibytes (MiB). Para cargar bloques más grandes (hasta 4000 MiB), consulte Put Block.

En la versión 2020-10-02 y posteriores, se admite la autorización de Azure Active Directory para el origen de la operación de copia.

Un blob puede tener un máximo de 100 000 bloques sin confirmar en cualquier momento. Si se supera este máximo, el servicio devuelve el código de estado 409 (RequestEntityTooLargeBlockCountExceedsLimit).

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 From URL) 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 From URL)
Versión 2020-04-08 y posteriores 4000 MiB Aproximadamente 190,7 tebibytes (TiB) (4000 MiB × 50 000 bloques) 5000 MiB
Versiones anteriores a 2020-04-08 100 MiB Aproximadamente 4,75 TiB (100 MiB × 50 000 bloques) 256 MiB

Después de cargar un conjunto de bloques, puede crear o actualizar el blob en el servidor desde este conjunto mediante una llamada a la operación Put Block List . Cada bloque del conjunto se identifica mediante un identificador de bloque único dentro de ese blob. El ámbito de los identificadores de bloque es el blob, de modo que diferentes blobs pueden tener bloques con el mismo identificador.

Si llama a Put Block From URL en un blob que aún no existe, se crea un nuevo blob en bloques con una longitud de contenido de 0. Este blob lo enumera la operación List Blobs si se especifica la opción include=uncommittedblobs. El bloque o los bloques cargados no se confirman hasta que se llama a Put Block List en el nuevo blob. Un blob creado de esta manera se mantiene en el servidor durante una semana. Si no ha agregado más bloques o bloques confirmados al blob dentro de ese período de tiempo, el blob se recopila como elemento no utilizado.

Un bloque que se ha cargado correctamente con la Put Block From URL operación no forma parte de un blob hasta que se confirma con Put Block List. Antes de Put Block List llamar a para confirmar el blob nuevo o actualizado, las llamadas a Get Blob devuelven el contenido del blob sin incluir el bloque no confirmado.

Si carga un bloque que tiene el mismo identificador de bloque que otro bloque que aún no se ha confirmado, el último bloque cargado con ese identificador se confirma en la siguiente operación correcta Put Block List .

Después de llamar a Put Block List, todos los bloques sin confirmar especificados en la lista de bloques se confirman como parte del nuevo blob. Los bloques no confirmados que no se especificaron en la lista de bloques del blob se recopilan y quitan de Blob Storage. Los bloques no confirmados también se recopilan como elementos no utilizados si no hay llamadas correctas a Put Block From URL o Put Block List en el mismo blob en una semana después de la última operación correcta Put Block From URL . Si se llama a Put Blob en el blob, los bloques no confirmados se recopilan como elementos no utilizados.

Si el blob tiene una concesión activa, el cliente debe especificar un identificador de concesión válido en la solicitud para escribir un bloque en el blob. 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).

Para un blob especificado, todos los identificadores de bloque deben tener la misma longitud. Si un bloque se carga con un identificador de bloque de una longitud diferente a la de los identificadores de bloque de los bloques no confirmados existentes, el servicio devuelve el código de respuesta de error 400 (solicitud incorrecta).

La llamada Put Block From URL a no actualiza la hora de la última modificación de un blob existente.

Una llamada a Put Block From URL en un blob en páginas devuelve un error.

Llamar a Put Block From URL en un blob "archive" devuelve un error y llamarlo en un hot blob o cool no cambia el nivel de blob.

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 From URL las solicitudes basadas en el tipo de cuenta de almacenamiento:

Operación Tipo de cuenta de almacenamiento Categoría de facturación
Put Block From URL (cuentade destino 1) Blobs en bloques Premium
De uso general, estándar, v2
De uso general, estándar, v1		 Operaciones de escritura
Put Block From URL (cuentade origen 2) Blobs en bloques Premium
De uso general, estándar, v2
De uso general, estándar, v1		 Lee operaciones.

1La cuenta de destino se cobra por una transacción para iniciar la escritura.
2La cuenta de origen incurre en una transacción para cada solicitud de lectura en el objeto de origen.

Además, si las cuentas de origen y destino residen en regiones diferentes (por ejemplo, Norte de EE. UU. y Sur de EE. UU.), el ancho de banda que se usa para transferir la solicitud se cobra a la cuenta de almacenamiento de origen como salida. Las salidas entre cuentas de la misma región son gratuitas.

Para obtener información sobre los precios de las categorías de facturación especificadas, consulte precios Azure Blob Storage.

Consulte también