Put Block List

Artigo
02/07/2024

A operação Put Block List grava um blob especificando a lista de IDs de bloco que constituem o blob. Para ser gravado como parte de um blob, um bloco deve ter sido gravado com êxito no servidor em uma operação Put Block anterior.

Você pode chamar Put Block List para atualizar um blob carregando apenas os blocos que foram alterados e, em seguida, confirmando os blocos novos e existentes juntos. Você pode fazer isso especificando se deseja confirmar um bloco da lista de bloqueios confirmados ou da lista de bloqueios não confirmados ou confirmar a versão carregada mais recentemente do bloco, seja qual for a lista à qual ele pertence.

Solicitação

Você pode construir a solicitação da Put Block List seguinte maneira. Recomendamos que você use HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento:

URI de solicitação do método PUT	Versão HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Solicitação de serviço de armazenamento emulado

Ao fazer uma solicitação no serviço de armazenamento emulado, especifique o nome do host do emulador e a porta do serviço Blob como 127.0.0.1:10000, seguido pelo nome da conta de armazenamento emulada:

URI de solicitação do método PUT	Versão HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist`	HTTP/1.1

O emulador de armazenamento dá suporte apenas a tamanhos de blob de até 2 gibibytes (GiB).

Para obter mais informações, consulte Usar o emulador Azurite para desenvolvimento local do armazenamento do Azure.

Parâmetros do URI

Você pode especificar os seguintes parâmetros adicionais no URI da solicitação:

Parâmetro	Descrição
`timeout`	Opcional. O parâmetro `timeout` é expresso em segundos. Para obter mais informações, consulte Definir tempos limite para operações do serviço Blob.

Cabeçalhos da solicitação

Os cabeçalhos de solicitação obrigatórios e opcionais são descritos na tabela a seguir:

Cabeçalho da solicitação	Descrição
`Authorization`	Obrigatórios. Especifica o esquema de autorização, o nome da conta e a assinatura. Para saber mais, confira Autorizar solicitações para o Armazenamento do Azure.
`Date` ou `x-ms-date`	Obrigatórios. Especifica o UTC (Tempo Universal Coordenado) para a solicitação. Para saber mais, confira Autorizar solicitações para o Armazenamento do Azure.
`x-ms-version`	Necessário para todas as solicitações autorizadas. Especifica a versão da operação a ser usada para esta solicitação. Para obter mais informações, consulte Controle de versão para os Serviços de Armazenamento do Azure.
`Content-Length`	Obrigatórios. O comprimento do conteúdo da solicitação, em bytes. Esse cabeçalho refere-se ao comprimento do conteúdo da lista de blocos, não ao blob em si.
`Content-MD5`	Opcional. Um hash MD5 do conteúdo da solicitação. O hash é usado para verificar a integridade do conteúdo da solicitação durante o transporte. Se os dois hashes não corresponderem, a operação falhará com o código de erro 400 (Solicitação inválida). Esse cabeçalho está associado ao conteúdo da solicitação e não ao conteúdo do próprio blob.
`x-ms-content-crc64`	Opcional. Um hash CRC64 do conteúdo da solicitação. O hash é usado para verificar a integridade do conteúdo da solicitação durante o transporte. Se os dois hashes não corresponderem, a operação falhará com o código de erro 400 (Solicitação inválida). Esse cabeçalho está associado ao conteúdo da solicitação e não ao conteúdo do próprio blob. Se os cabeçalhos Content-MD5 e x-ms-content-crc64 estiverem presentes, a solicitação falhará com um 400 (Solicitação Incorreta). Esse cabeçalho tem suporte na versão 2019-02-02 e posterior.
`x-ms-blob-cache-control`	Opcional. Define o controle de cache do blob. Se essa propriedade for especificada, ela será armazenada com o blob e retornada com uma solicitação de leitura. Se a propriedade não for especificada com a solicitação, ela será limpa para o blob se a solicitação for bem-sucedida.
`x-ms-blob-content-type`	Opcional. Define o tipo de conteúdo do blob. Se for especificada, essa propriedade será armazenada com o blob e retornada com uma solicitação de leitura. Se o tipo de conteúdo não for especificado, ele será definido como o tipo padrão, que é `application/octet-stream`.
`x-ms-blob-content-encoding`	Opcional. Define a codificação do conteúdo do blob. Se for especificada, essa propriedade será armazenada com o blob e retornada com uma solicitação de leitura. Se a propriedade não for especificada com a solicitação, ela será limpa para o blob se a solicitação for bem-sucedida.
`x-ms-blob-content-language`	Opcional. Define o idioma de conteúdo do blob. Se for especificada, essa propriedade será armazenada com o blob e retornada com uma solicitação de leitura. Se a propriedade não for especificada com a solicitação, ela será limpa para o blob se a solicitação for bem-sucedida.
`x-ms-blob-content-md5`	Opcional. Um hash MD5 do conteúdo do blob. Esse hash não é validado porque os hashes dos blocos individuais foram validados quando cada um foi carregado. A operação Obter Blob retorna o valor desse cabeçalho no cabeçalho de resposta Content-MD5. Se essa propriedade não for especificada com a solicitação, ela será limpa para o blob se a solicitação for bem-sucedida.
`x-ms-meta-name:value`	Opcional. Pares nome-valor definidos pelo usuário associados ao blob. A partir da versão 2009-09-19, os nomes de metadados devem seguir as regras de nomenclatura para identificadores C#.
`x-ms-encryption-scope`	Opcional. Indica o escopo de criptografia a ser usado para criptografar o blob. Esse valor deve corresponder ao escopo de criptografia usado para criptografar todos os blocos que estão sendo confirmados. Esse cabeçalho tem suporte na versão 2019-02-02 e posterior.
`x-ms-encryption-context`	Opcional. O padrão é "Vazio". Se o valor for definido, ele definirá metadados do sistema de blob. Comprimento máximo-1024. Válido somente quando o Namespace Hierárquico está habilitado para a conta. Esse cabeçalho tem suporte nas versões 2021-08-06 e posteriores.
`x-ms-tags`	Opcional. Define as marcas codificadas de cadeia de caracteres de consulta especificadas no blob. Para obter informações adicionais, consulte a seção Comentários . Com suporte na versão 2019-12-12 e posterior.
`x-ms-lease-id:<ID>`	Obrigatório se o blob tiver uma concessão ativa. Para executar essa operação em um blob com uma concessão ativa, especifique a ID de concessão válida para esse cabeçalho.
`x-ms-client-request-id`	Opcional. Fornece um valor opaco gerado pelo cliente com um limite de caracteres KiB (1 kibibyte) que é registrado nos logs de análise quando o log da análise de armazenamento é configurado. É altamente recomendável que você use esse cabeçalho para correlacionar atividades do lado do cliente com solicitações recebidas pelo servidor.
`x-ms-blob-content-disposition`	Opcional. Define o cabeçalho `Content-Disposition` do blob. Disponível para a versão 2013-08-15 e posterior. O `Content-Disposition` campo de cabeçalho transmite informações adicionais sobre como processar o conteúdo da resposta e pode ser usado para anexar metadados adicionais. Por exemplo, se estiver definido `attachment`como , esse cabeçalho indicará que o agente do usuário não deve exibir a resposta, mas deve mostrar uma caixa de diálogo Salvar como. A resposta das operações Obter Propriedades de Blob e Obter Blob inclui o cabeçalho de disposição de conteúdo.
`x-ms-access-tier`	Opcional. Versão 2018-11-09 e posterior. Indica a camada a ser definida em um blob. Para blobs de blocos, esse cabeçalho tem suporte no armazenamento de blobs ou contas de uso geral v2 somente com a versão 2018-11-09 e posterior. Os valores válidos para camadas de blob de blocos são `Hot`, `Cool`, `Cold`e `Archive`. Observação: `Cold` a camada tem suporte para a versão 2021-12-02 e posterior. Para obter informações detalhadas sobre camadas de blob de blocos , consulte Camadas de armazenamento frequentes, esporádicas e de arquivos.
`x-ms-immutability-policy-until-date`	Versão 2020-06-12 e posterior. Especifica a data de retenção até ser definida no blob. Essa é a data até a qual o blob pode ser protegido contra modificação ou exclusão. Segue RFC1123 formato.
`x-ms-immutability-policy-mode`	Versão 2020-06-12 e posterior. Especifica o modo de política de imutabilidade a ser definido no blob. Os valores válidos são `unlocked` e `locked`. O `unlocked` valor indica que os usuários podem alterar a política aumentando ou diminuindo a data de retenção até . O `locked` valor indica que essas ações são proibidas.
`x-ms-legal-hold`	Versão 2020-06-12 e posterior. Especifica a retenção legal a ser definida no blob. Os valores válidos são `true` e `false`.
`x-ms-expiry-option`	Opcional. Versão 2023-08-03 e posterior. Especifica a opção de data de validade da solicitação, consulte ExpiryOption. Esse cabeçalho é válido para contas com namespace hierárquico habilitado.
`x-ms-expiry-time`	Opcional. Versão 2023-08-03 e posterior. Especifica a hora em que o blob está definido para expirar. O formato da data de validade varia de acordo `x-ms-expiry-option`com . Para obter mais informações, consulte ExpiryOption. Esse cabeçalho é válido para contas com namespace hierárquico habilitado. O `expiryTime` já presente em um blob não será limpo se a solicitação não contiver um novo valor de `expiryTime`

Essa operação também dará suporte ao uso de cabeçalhos condicionais para confirmar a lista de bloqueio somente se uma determinada condição for atendida. Para obter mais informações, consulte Especificar cabeçalhos condicionais para operações de Armazenamento de Blobs.

Cabeçalhos de solicitação (chaves de criptografia fornecidas pelo cliente)

A partir da versão 2019-02-02, você pode especificar os cabeçalhos a seguir na solicitação para criptografar um blob com uma chave fornecida pelo cliente. A criptografia com uma chave fornecida pelo cliente (e o conjunto correspondente de cabeçalhos) é opcional.

Cabeçalho da solicitação	Descrição
`x-ms-encryption-key`	Obrigatórios. A chave de criptografia AES-256 codificada em Base64.
`x-ms-encryption-key-sha256`	Obrigatórios. O hash SHA256 codificado em Base64 da chave de criptografia.
`x-ms-encryption-algorithm: AES256`	Obrigatórios. Especifica o algoritmo a ser usado para criptografia. O valor deste cabeçalho deve ser `AES256`.

Corpo da solicitação

No corpo da solicitação, você pode especificar a lista de blocos que o Armazenamento de Blobs deve marcar para o bloco solicitado. Dessa forma, você pode atualizar um blob existente inserindo, substituindo ou excluindo blocos individuais, em vez de recarregar todo o blob. Depois de carregar o bloco ou os blocos que foram alterados, você pode confirmar uma nova versão do blob confirmando os novos blocos junto com os blocos existentes que deseja manter.

Para atualizar um blob, você pode especificar que o serviço deve procurar uma ID de bloco na lista de blocos confirmados, na lista de blocos não confirmados ou na lista de blocos não confirmados primeiro e depois na lista de blocos confirmados. Para indicar qual abordagem usar, especifique a ID do bloco que está dentro do elemento XML apropriado dentro do corpo da solicitação, da seguinte maneira:

Especifique a ID do bloco dentro do Committed elemento para indicar que o Armazenamento de Blobs deve pesquisar apenas a lista de blocos confirmados para o bloco nomeado. Se o bloco não for encontrado na lista de blocos confirmados, ele não será gravado como parte do blob e o Armazenamento de Blobs retornará status código 400 (Solicitação Incorreta).
Especifique a ID do bloco dentro do Uncommitted elemento para indicar que o Armazenamento de Blobs deve pesquisar apenas a lista de blocos não confirmados para o bloco nomeado. Se o bloco não for encontrado na lista de blocos não confirmados, ele não será gravado como parte do blob e o Armazenamento de Blobs retornará status código 400 (Solicitação Incorreta).
Especifique a ID do bloco dentro do Latest elemento para indicar que o Armazenamento de Blobs deve primeiro pesquisar a lista de blocos não confirmados. Se o bloco for encontrado na lista de não confirmados, essa versão do bloco será a mais recente e deverá ser gravada no Blob. Se o bloco não for encontrado na lista não confirmada, o serviço deverá pesquisar o bloco nomeado na lista de blocos confirmados e gravar esse bloco no blob se ele for encontrado.

O corpo da solicitação para esta versão do Put Block List usa o seguinte 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>

Solicitação de exemplo

Para demonstrar Put Block List, suponha que você tenha carregado três blocos que agora deseja confirmar. O exemplo a seguir confirma um novo blob indicando que a última versão de cada bloco listado deve ser usada. Não é necessário saber se esses blocos já foram confirmados.

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>

Em seguida, vamos supor que você deseja atualizar o blob. O novo blob tem as seguintes alterações:

Um novo bloco com a ID ANAAAA==. Esse bloco deve primeiro ser carregado com uma chamada para Colocar Bloco e aparece na lista de bloqueios não confirmados até a chamada para Put Block List.
Uma versão atualizada do bloco com a ID AZAAAA==. Esse bloco deve primeiro ser carregado com uma chamada para Colocar Bloco e aparece na lista de bloqueios não confirmados até a chamada para Put Block List.
Remoção do bloco com a ID AAAAAA==. Como esse bloco não está incluído na próxima chamada para Put Block List, o bloco é efetivamente removido do blob.

O exemplo a seguir mostra a chamada para Put Block List que atualiza o 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>

Resposta

A resposta inclui um código de status HTTP e um conjunto de cabeçalhos de resposta.

Código de status

Uma operação bem-sucedida retorna o código de status 201 (Criado).

Para obter mais informações sobre códigos de status, consulte Códigos de status e de erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os cabeçalhos a seguir. A resposta também pode incluir cabeçalhos padrão HTTP adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Resposta	Descrições
`ETag`	A marca de entidade contém um valor que o cliente pode usar para executar operações `GET/PUT` condicionais usando o cabeçalho de solicitação `If-Match`. Se a versão da solicitação for 2011-08-18 ou posterior, o valor de ETag será colocado entre aspas.
`Last-Modified`	A data e a hora da última modificação feita no blob. O formato da data segue RFC 1123. Para obter mais informações, consulte Representar valores de data/hora em cabeçalhos. Qualquer operação que modificar o blob, incluindo uma atualização dos metadados ou das propriedades do blob, alterará a hora da última modificação do blob.
`Content-MD5`	Retornado para que o cliente possa marcar quanto à integridade do conteúdo da mensagem. Esse cabeçalho refere-se ao conteúdo da solicitação (nesse caso, a lista de blocos e não o conteúdo do blob em si). Para a versão 2019-02-02 e posterior, esse cabeçalho é retornado somente quando a solicitação tem esse cabeçalho.
`x-ms-content-crc64`	Para a versão 2019-02-02 e posterior, esse cabeçalho é retornado para que o cliente possa marcar quanto à integridade do conteúdo da mensagem. Esse cabeçalho refere-se ao conteúdo da solicitação (nesse caso, a lista de blocos e não o conteúdo do blob em si). Esse cabeçalho é retornado quando `Content-md5` o cabeçalho não está presente na solicitação.
`x-ms-request-id`	Identifica exclusivamente a solicitação que foi feita e você pode usá-la para solucionar problemas da solicitação. Para obter mais informações, consulte Solucionar problemas de operações de API.
`x-ms-version`	A versão do Armazenamento de Blobs usada para executar a solicitação. Esse cabeçalho é retornado para solicitações feitas na versão 2009-09-19 e posterior.
`Date`	Um valor de data/hora UTC gerado pelo serviço, que indica quando a resposta foi iniciada.
`x-ms-request-server-encrypted: true/false`	Versão 2015-12-11 e posterior. O valor desse cabeçalho será definido `true` como se o conteúdo da solicitação for criptografado com êxito usando o algoritmo especificado. Caso contrário, o valor será definido como `false`.
`x-ms-encryption-key-sha256`	Versão 2019-02-02 e posterior. Esse cabeçalho será retornado se a solicitação tiver usado uma chave fornecida pelo cliente para criptografia, para que o cliente possa garantir que o conteúdo da solicitação seja criptografado com êxito usando a chave fornecida.
`x-ms-encryption-scope`	Versão 2019-02-02 e posterior. Esse cabeçalho será retornado se a solicitação tiver usado um escopo de criptografia, para que o cliente possa garantir que o conteúdo da solicitação seja criptografado com êxito usando o escopo de criptografia.
`x-ms-version-id: <DateTime>`	Versão 2019-12-12 e posterior. Retorna um valor opaco `DateTime` que identifica exclusivamente o blob. O valor desse cabeçalho indica a versão do blob e pode ser usado em solicitações subsequentes para acessar o blob.
`x-ms-client-request-id`	Pode ser usado para solucionar problemas de solicitações e suas respostas correspondentes. O valor desse cabeçalho será igual ao valor do `x-ms-client-request-id` cabeçalho se ele estiver presente na solicitação e o valor não contiver mais de 1.024 caracteres ASCII visíveis. Se o `x-ms-client-request-id` cabeçalho não estiver presente na solicitação, ele não estará presente na resposta.

Resposta de exemplo

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>

Autorização

A autorização é necessária ao chamar qualquer operação de acesso a dados no Armazenamento do Azure. Você pode autorizar a Put Block List operação conforme descrito abaixo.

Se uma solicitação especificar marcas com o cabeçalho da x-ms-tags solicitação, o chamador deverá atender aos requisitos de autorização da operação Definir Marcas de Blob .

O Armazenamento do Azure dá suporte ao uso de Microsoft Entra ID para autorizar solicitações para dados de blob. Com Microsoft Entra ID, você pode usar o RBAC (controle de acesso baseado em função) do Azure para conceder permissões a uma entidade de segurança. A entidade de segurança pode ser um usuário, um grupo, uma entidade de serviço de aplicativo ou uma identidade gerenciada do Azure. A entidade de segurança é autenticada por Microsoft Entra ID para retornar um token OAuth 2.0. Em seguida, o token pode ser usado para autorizar uma solicitação no serviço de Blob.

Para saber mais sobre a autorização usando Microsoft Entra ID, consulte Autorizar o acesso a blobs usando Microsoft Entra ID.

Permissões

Veja abaixo a ação RBAC necessária para que um usuário, grupo ou entidade de serviço Microsoft Entra chame a Put Block List operação e a função rbac interna do Azure com privilégios mínimos que inclua esta ação:

Ação rbac do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Função interna com privilégios mínimos:Colaborador de Dados de Blob de Armazenamento

Para saber mais sobre como atribuir funções usando o RBAC do Azure, confira Atribuir uma função do Azure para acesso aos dados de blob.

Uma SAS (assinatura de acesso compartilhado) fornece acesso delegado seguro aos recursos em uma conta de armazenamento. Com uma SAS, você tem controle granular sobre como um cliente pode acessar dados. Você pode especificar qual recurso o cliente pode acessar, quais permissões eles têm para esses recursos e por quanto tempo a SAS é válida.

A Put Block List operação dá suporte a três tipos de assinaturas de acesso compartilhado: SAS de delegação de usuário, SAS de serviço e SAS de conta.

Como prática recomendada de segurança, recomendamos que você use Microsoft Entra credenciais em vez da chave de conta de armazenamento, que pode ser comprometida com mais facilidade. Se o design do aplicativo exigir assinaturas de acesso compartilhado, use Microsoft Entra credenciais para criar uma SAS de delegação de usuário, quando possível.

Quando o acesso à Chave Compartilhada não for permitido para a conta de armazenamento, um token SAS de serviço ou um token SAS da conta não será permitido em uma solicitação para o Armazenamento de Blobs. Para saber mais, confira Entender como a não permissão da Chave Compartilhada afeta os tokens SAS.

SAS de delegação do usuário

Uma SAS de delegação de usuário é protegida com Microsoft Entra credenciais e também pelas permissões especificadas para a SAS.

Chamar a Put Block List operação usando um token SAS delegado a um contêiner ou recurso de blob requer a permissão Gravar (w) como parte do token SAS de delegação do usuário.

Para saber mais sobre a SAS de delegação de usuário, consulte Criar uma SAS de delegação de usuário.

SAS de serviço

Uma SAS de serviço é protegida com a chave da conta de armazenamento. Uma SAS de serviço delega acesso a um recurso em um único serviço de Armazenamento do Azure, como o armazenamento de blobs.

Chamar a Put Block List operação usando um token SAS delegado a um contêiner ou recurso de blob requer a permissão Gravar (w) como parte do token SAS de serviço.

Para saber mais sobre a SAS de serviço, consulte Criar uma SAS de serviço.

SAS de Conta

Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma SAS de conta delega acesso a recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de uma SAS de serviço ou de delegação do usuário também estão disponíveis por meio de uma SAS de conta.

A tabela a seguir indica o tipo de recurso assinado e as permissões assinadas a serem especificadas ao delegar acesso:

Operação	Serviço assinado	Tipo de recurso assinado	Permissão assinada
Put Block List	Blob (b)	Objeto (o)	Gravação (w)

Para saber mais sobre a SAS da conta, consulte Criar uma SAS de conta.

A Put Block List operação dá suporte à autorização de Chave Compartilhada. A autorização com chaves de conta não é recomendada para a maioria dos cenários, pois é menos segura.

A Microsoft recomenda não permitir a autorização de Chave Compartilhada para a conta de armazenamento quando possível. Para obter mais informações, consulte Impedir autorização com chave compartilhada.

Comentários

A operação Put Block List impõe a ordem em que os blocos deverão ser combinados para criar um blob.

A mesma ID de bloco pode ser especificada mais de uma vez na lista de blocos. Se uma ID de bloco for especificada mais de uma vez, ela representará o intervalo de bytes em cada um desses locais na lista de blocos para o blob confirmado final. Se uma ID de bloco aparecer mais de uma vez na lista, ambas as instâncias da ID do bloco deverão ser especificadas na mesma lista de blocos. Ou seja ambas as instâncias devem ser especificadas nos elementos Committed, Uncommitted ou Latest.

Com Put Block Listo , você pode modificar um blob existente inserindo, atualizando ou excluindo blocos individuais sem precisar carregar o blob inteiro novamente. Você pode especificar IDs do bloco da lista de contatos bloqueados confirmada atual e da lista de blocos não confirmados para criar um novo blob ou para atualizar o conteúdo de um blob existente. Dessa forma, você pode atualizar um blob especificando alguns novos blocos da lista de blocos não confirmados e o restante da lista de blocos confirmados, que já fazem parte do blob existente.

Se uma ID de bloco for especificado no elemento Latest, e a mesma ID do bloco existir em listas de contatos bloqueados confirmadas e não confirmadas, Put Block List confirmará o bloco da lista de blocos não confirmados. Se a ID do bloco existir na lista de blocos confirmados, mas não na lista de bloqueios não confirmados, Put Block List confirmará o bloco da lista de bloqueios confirmados.

Cada bloco em um blob de blocos pode ter um tamanho diferente. Um blob de blocos pode incluir no máximo 50.000 blocos confirmados. O número máximo de blocos não confirmados que podem ser associados a um blob é 100.000.

A tabela a seguir descreve o máximo permitido de tamanhos de bloco e blob, por versão de serviço:

Versão do serviço	Tamanho máximo do bloco (via `Put Block`)	Tamanho máximo do blob (via `Put Block List`)	Tamanho máximo do blob por meio de operação de gravação única (via `Put Blob`)
Versão 12/12/2019 e posterior	4.000 mebibytes (MiB)	Aproximadamente 190,7 tebibytes (TiB) (4.000 MiB × 50.000 blocos)	5.000 MiB
Versões 2016-05-31 a 2019-07-07	100 MiB	Aproximadamente 4,75 TiB (100 MiB × 50.000 blocos)	256 MiB
Versões anteriores a 31/05/2016	4 MiB	Aproximadamente 195 GiB (4 MiB × 50.000 blocos)	64 MiB

Quando você chama Put Block List para atualizar um blob existente, as propriedades existentes e os metadados de blob são substituídos. No entanto, todos os instantâneos existentes são mantidos com o blob. Você pode usar os cabeçalhos de solicitação condicionais para executar a operação somente se uma condição especificada for atendida.

Se a Put Block List operação falhar devido a um bloco ausente, você precisará carregar o bloco ausente.

Todos os blocos não confirmados serão coletados se não houver chamadas bem-sucedidas para Put Block ou Put Block List no blob dentro de uma semana após a última operação bem-sucedida Put Block . Se Put Blob for chamado no blob, todos os blocos não confirmados serão coletados como lixo.

Se as marcas forem fornecidas no x-ms-tags cabeçalho, elas deverão ser codificadas na cadeia de caracteres de consulta. As chaves de marca e os valores devem estar em conformidade com os requisitos de nomenclatura e comprimento, conforme especificado em Set Blob Tags. Além disso, o x-ms-tags cabeçalho pode conter marcas de até 2 KiB de tamanho. Se mais marcas forem necessárias, use a operação Definir Marcas de Blob .

Se o blob tiver uma concessão ativa, o cliente deverá especificar uma ID de concessão válida na solicitação para confirmar a lista de bloqueios. Se o cliente não especificar uma ID de concessão ou especificar uma ID de concessão inválida, o Armazenamento de Blobs retornará status código 412 (Falha na pré-condição). Se o cliente especificar uma ID de concessão, mas o blob não tiver uma concessão ativa, o Armazenamento de Blobs também retornará status código 412 (Falha na pré-condição). Se o cliente especificar uma ID de concessão em um blob que ainda não existe, o Armazenamento de Blobs retornará status código 412 (Falha na Pré-condição) para solicitações feitas na versão 2013-08-15 ou posterior. Para versões anteriores, o Armazenamento de Blobs retorna status código 201 (Criado).

Se o blob tiver uma concessão ativa e você chamar Put Block List para atualizar o blob, a concessão será é mantida no blob atualizado.

Put Block List é aplicável apenas a blobs de bloco. A chamada de Put Block List em um blob de páginas resulta no código de status 400 (Solicitação Incorreta).

A substituição de um blob arquivado falhará e a substituição de um hot blob ou cool herdará a camada do blob antigo se o cabeçalho x-ms-access-tier não for fornecido.

Cobrança

As solicitações de preços podem ser originadas de clientes que usam APIs de Armazenamento de Blobs, diretamente por meio da API REST do Armazenamento de Blobs ou de uma biblioteca de clientes do Armazenamento do Azure. Essas solicitações acumulam encargos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura se acumulam em uma categoria de cobrança diferente das transações de gravação. A tabela a seguir mostra a categoria de cobrança para Put Block List solicitações com base no tipo de conta de armazenamento:

Operação	Tipo de conta de armazenamento	Categoria de cobrança
Put Block List	Blob de blocos Premium Uso geral v2 Standard Uso geral v1 Standard	Operações de gravação

Para saber mais sobre os preços da categoria de cobrança especificada, confira Preços Armazenamento de Blobs do Azure.

Confira também

Entender blobs de blocos, blobs de acréscimo e blobs de páginas
Autorizar solicitações para o Armazenamento do Azure
Status e códigos de erro
Códigos de erro do serviço Blob
Definir tempos limite para operações do serviço Blob