Exportar (0) Imprimir
Expandir todo

Put Block List

Actualizado: enero de 2014

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

Puede llamar a Put Block List para actualizar un blob cargando solo los bloques que han cambiado y luego confirmando a la vez los bloques nuevos y los existentes. Puede hacerlo especificando si se debe confirmar un bloque de la lista de bloques confirmados o de la lista de bloques sin confirmar, o bien confirmar la versión del bloque que se ha cargado en último lugar, independientemente de la lista a la que pertenezca.

La solicitud Put Block List se puede construir como sigue. Se recomienda HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento:

 

  URI de solicitud del método PUT Versión de HTTP

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist

HTTP/1.1

Al realizar una solicitud en el servicio de almacenamiento emulado, especifique 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 emulado:

 

  URI de solicitud del método PUT Versión de HTTP

http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist

HTTP/1.1

Tenga en cuenta que el emulador de almacenamiento solo admite blobs con un tamaño máximo de 2 GB.

Para obtener más información, vea Uso del emulador de almacenamiento de Azure para desarrollo y prueba.

Se pueden especificar los parámetros adicionales siguientes en el URI de solicitud.

 

Parámetro Descripción

timeout

Opcional. El parámetro timeout se expresa en segundos. Para obtener más información, vea Establecer los tiempos de espera para las operaciones del servicio Blob.

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

 

Encabezado de solicitud Descripción

Authorization

Requerido. Especifica el esquema de autenticación, el nombre de la cuenta y la firma. Para obtener más información, vea Autenticación para los servicios de almacenamiento de Azure.

Date O bien x-ms-date

Requerido. Especifica la hora universal coordinada (UTC) para la solicitud. Para obtener más información, vea Autenticación para los servicios de almacenamiento de Azure.

x-ms-version

Obligatorio para todas las solicitudes autenticadas. Especifica la versión de la operación que se utiliza para esta solicitud. Para obtener más información, vea Control de versiones de los servicios de almacenamiento de Azure.

Content-Length

Requerido. La longitud del contenido de la solicitud, en bytes. Tenga en cuenta que este encabezado hace referencia a la longitud del contenido de la lista de bloques, no del blob en sí.

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 producirá un error con el código de estado 400 (Solicitud incorrecta).

Tenga en cuenta que este encabezado está asociado al contenido de la solicitud, no al contenido del blob en sí.

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 no se especifica esta propiedad con la solicitud, se desactiva para el blob si la solicitud es correcta.

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 no se especifica esta propiedad con la solicitud, se desactiva para el blob si la solicitud es correcta.

x-ms-blob-content-language

Opcional. Establece el idioma del 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 esta propiedad con la solicitud, se desactiva para el blob si la solicitud es correcta.

x-ms-blob-content-md5

Opcional. Hash MD5 del contenido del blob. Tenga en cuenta que este hash no se valida, ya que los valores hash de cada uno de los bloques se validaron en el momento de cargarlos.

La operación Get Blob devuelve el valor de este encabezado en el encabezado de respuesta Content-MD5.

Si no se especifica esta propiedad con la solicitud, se desactiva para el blob si la solicitud es correcta.

x-ms-meta-name:value

Opcional. Pares nombre-valor definidos por el usuario asociados al blob.

Tenga en cuenta que, a partir de la versión 2009-09-19, los nombres de los metadatos deben cumplir las reglas de nomenclatura para los Identificadores de C#.

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 KB que se graba en los registros de análisis cuando el registro de análisis de almacenamiento está habilitado. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes recibidas por el servidor. Para obtener más información, vea Acerca del registro del análisis de almacenamiento y Registro de Windows Azure: usar registros para realizar el seguimiento de las solicitudes de almacenamiento.

x-ms-blob-content-disposition

Opcional. Establece el encabezado Content-Disposition del blob. Disponible para las versiones 2013-08-15 y posteriores.

El campo de encabezado Content-Disposition transmite información adicional sobre cómo procesar la carga de respuesta y también se puede usar para adjuntar metadatos adicionales. Por ejemplo, si se establece en attachment, indica que el agente de usuario no debe mostrar la respuesta, sino que debe mostrar en su lugar un cuadro de diálogo Guardar como.

La respuesta de las operaciones Get Blob y Get Blob Properties incluye el encabezado content-disposition.

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 obtener más información, vea Especificar encabezados condicionales para las operaciones del servicio Blob.

En el cuerpo de la solicitud se puede especificar la lista de bloques que el servicio Blob debe comprobar para el bloque solicitado. De esta forma puede actualizar un blob existente insertando, reemplazando o eliminando bloques de uno en uno, en lugar de volver a cargar el blob completo. Después de cargar el bloque o los bloques que han cambiado, puede confirmar una versión nueva del blob; para ello, debe confirmar los bloques nuevos junto con los bloques existentes que desea mantener.

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é método se debe utilizar, especifique el identificador de bloque en el elemento XML adecuado del cuerpo de la solicitud, de la forma siguiente:

  • Especifique el identificador del bloque dentro del elemento Committed para indicar que el servicio Blob debe buscar el bloque indicado en la lista de bloques confirmados. Si el bloque no se encuentra en la lista de bloques confirmados, no se escribirá como parte del blob y el servicio Blob devolverá el código de estado 400 (Solicitud incorrecta).

  • Especifique el identificador del bloque dentro del elemento Uncommitted para indicar que el servicio Blob debe buscar el bloque indicado en la lista de bloques sin confirmar. Si el bloque no se encuentra en la lista de bloques sin confirmar, no se escribirá como parte del blob y el servicio Blob devolverá el código de estado 400 (Solicitud incorrecta).

  • Especifique el identificador del bloque dentro del elemento Latest para indicar que el servicio Blob 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 indicado no se encuentra en la lista de bloques sin confirmar, el servicio debe buscarlo en la lista de bloques confirmados y, si lo encuentra, escribirlo en el blob.

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

<?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>

Para ver cómo funciona 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, imagine que desea actualizar el blob. El nuevo blob tendrá los cambios siguientes:

  • Un nuevo bloque con el identificador ANAAAA==. Este bloque primero debe cargarse con una llamada a Put Block y aparecerá en la lista de bloques sin confirmar hasta la llamada a Put Block List.

  • Una versión actualizada del bloque con el identificador AZAAAA==. Este bloque primero debe cargarse con una llamada a Put Block y aparecerá en la lista de bloques sin confirmar hasta 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 quitará 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
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>

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

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

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

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 cumplen la especificación del protocolo HTTP/1.1.

 

Respuesta 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 una más reciente, el valor ETag estará 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 Representación de valores de fecha u 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

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, lo que en este caso significa la lista de bloques y no el contenido del blob propiamente dicho.

x-ms-request-id

Este encabezado identifica de forma única la solicitud que se realizó y se puede utilizar para solucionar problemas relacionados con esta. Para obtener más información, vea Solucionar problemas relacionados con las operaciones de la API.

x-ms-version

Indica la versión del servicio Blob utilizado 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 generado por el servicio que indica la hora a la que se inició la respuesta.

Response Status:
HTTP/1.1 201 Created

Response Headers:
Transfer-Encoding: chunked
Content-MD5: oafL1+HS78x65+e39PGIIg==
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

La llamada a esta operación la puede realizar el propietario de la cuenta y cualquiera que disponga de una firma de acceso compartido con permiso para escribir en el blob o en su contenedor.

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 un identificador de bloque se especifica más de una vez, representará el intervalo de bytes de cada una de esas ubicaciones en la lista de bloques del 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 cargar el blob entero de nuevo. 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 esta forma, puede actualizar un blob especificando unos cuantos bloques de la lista de bloques sin confirmar y los demás de la lista de bloques confirmados, 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 bloques confirmados pero no en la lista de bloques sin confirmar, Put Block List confirma el bloque de la lista de bloques confirmados.

Es posible confirmar 50.000 bloques como máximo y el tamaño máximo de un blob que se puede confirmar mediante la operación Put Block List es de 200 GB. Si intenta confirmar más de 50.000 bloques, el servicio devuelve el código de estado 413 (Entidad solicitada demasiado grande). El servicio también devuelve información adicional sobre el error en la respuesta, incluyendo el número máximo de bloques permitido.

El número máximo de bloques sin confirmar que se pueden asociara a un blob es de 100.000, y el tamaño máximo de la lista de bloques sin confirmar es de 400 GB.

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 operación Put Block List debido a la ausencia de un bloque, será necesario cargar el bloque que falta.

Cualquier bloque sin confirmar será objeto de la recolección de elementos no utilizados si no hay llamadas correctas a Put Block o a Put Block List en el blob durante una semana desde la última operación Put Block correcta. Si se llama a Put Blob en el blob, cualquier bloque sin confirmar será objeto de la recolección de 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 poder 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, el servicio Blob 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 dispone de una concesión activa, el servicio Blob 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, el servicio Blob devolverá el código de estado 412 (Error de condición previa) para las solicitudes realizadas en la versión 2013-08-15 y posteriores; para las versiones anteriores, el servicio Blob devolverá 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).

Mostrar:
© 2014 Microsoft