Put Block List
A Put Block List
operação escreve um blob ao especificar a lista de IDs de bloco que compõem o blob. Para ser escrito como parte de um blob, um bloco deve ter sido escrito com êxito no servidor numa operação put block anterior.
Pode ligar Put Block List
para atualizar um blob ao carregar apenas os blocos que foram alterados e, em seguida, ao consolidar os blocos novos e existentes em conjunto. Pode fazê-lo ao especificar se pretende consolidar um bloco a partir da lista de blocos consolidado ou a partir da lista de blocos não comprometidos ou para consolidar a versão carregada mais recentemente do bloco, independentemente da lista à qual pertence.
Pedir
Pode construir o pedido da Put Block List
seguinte forma. Recomendamos que utilize HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento:
URI do pedido de método PUT | Versão HTTP |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
Pedido de serviço de armazenamento emulado
Quando estiver a fazer um pedido contra o serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e a porta do serviço Blob como 127.0.0.1:10000
, seguido do nome da conta de armazenamento emulada:
URI do pedido de método PUT | Versão HTTP |
---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
O emulador de armazenamento suporta apenas tamanhos de blobs de até 2 gibibytes (GiB).
Para obter mais informações, veja Utilizar o emulador do Azurite para o desenvolvimento local do Armazenamento do Azure.
Parâmetros URI
Pode especificar os seguintes parâmetros adicionais no URI do pedido:
Parâmetro | Description |
---|---|
timeout |
Opcional. O timeout parâmetro é expresso em segundos. Para obter mais informações, veja Definir tempos limite para operações do serviço Blob. |
Cabeçalhos do pedido
Os cabeçalhos de pedido obrigatórios e opcionais estão descritos na seguinte tabela:
Cabeçalho do pedido | Description |
---|---|
Authorization |
Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure. |
Date ou x-ms-date |
Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure. |
x-ms-version |
Necessário para todos os pedidos autorizados. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure. |
Content-Length |
Obrigatório. A duração do conteúdo do pedido, em bytes. Este cabeçalho refere-se ao comprimento do conteúdo da lista de blocos e não ao próprio blob. |
Content-MD5 |
Opcional. Um hash MD5 do conteúdo do pedido. Este hash é utilizado para verificar a integridade do conteúdo do pedido durante o transporte. Se os dois hashes não corresponderem, a operação falha com o código de erro 400 (Pedido Incorreto). Este cabeçalho está associado ao conteúdo do pedido e não ao conteúdo do próprio blob. |
x-ms-content-crc64 |
Opcional. Um Hash CRC64 do conteúdo do pedido. Este hash é utilizado para verificar a integridade do conteúdo do pedido durante o transporte. Se os dois hashes não corresponderem, a operação falha com o código de erro 400 (Pedido Incorreto). Este cabeçalho está associado ao conteúdo do pedido e não ao conteúdo do próprio blob. Se os cabeçalhos Content-MD5 e x-ms-content-crc64 estiverem presentes, o pedido falhará com um 400 (Pedido Incorreto). Este cabeçalho é suportado na versão 2019-02-02 e posterior. |
x-ms-blob-cache-control |
Opcional. Define o controlo de cache do blob. Se esta propriedade for especificada, é armazenada com o blob e devolvida com um pedido de leitura. Se a propriedade não for especificada com o pedido, será desmarcada para o blob se o pedido for bem-sucedido. |
x-ms-blob-content-type |
Opcional. Define o tipo de conteúdo do blob. Se for especificado, esta propriedade é armazenada com o blob e devolvida com um pedido de leitura. Se o tipo de conteúdo não for especificado, está definido para o tipo predefinido, que é application/octet-stream . |
x-ms-blob-content-encoding |
Opcional. Define a codificação de conteúdo do blob. Se for especificado, esta propriedade é armazenada com o blob e devolvida com um pedido de leitura. Se a propriedade não for especificada com o pedido, será desmarcada para o blob se o pedido for bem-sucedido. |
x-ms-blob-content-language |
Opcional. Define o idioma de conteúdo do blob. Se for especificado, esta propriedade é armazenada com o blob e devolvida com um pedido de leitura. Se a propriedade não for especificada com o pedido, será desmarcada para o blob se o pedido for bem-sucedido. |
x-ms-blob-content-md5 |
Opcional. Um Hash MD5 do conteúdo da bolha. Este hash não é validado porque os hashes dos blocos individuais foram validados quando cada um foi carregado. A operação Obter Blob devolve o valor deste cabeçalho no cabeçalho de resposta Content-MD5. Se esta propriedade não for especificada com o pedido, será desmarcada para o blob se o pedido for bem-sucedido. |
x-ms-meta-name:value |
Opcional. Pares nome-valor definidos pelo utilizador que estão associados ao blob. A partir da versão 2009-09-19, os nomes de metadados têm de cumprir as regras de nomenclatura dos identificadores C#. |
x-ms-encryption-scope |
Opcional. Indica o âmbito de encriptação a utilizar para encriptar o blob. Este valor tem de corresponder ao âmbito de encriptação utilizado para encriptar todos os blocos que estão a ser consolidados. Este cabeçalho é suportado na versão 2019-02-02 e posterior. |
x-ms-encryption-context |
Opcional. A predefinição é "Vazio". Se o valor estiver definido, irá definir metadados do sistema de blobs. Comprimento máximo-1024. Válido apenas quando o Espaço de Nomes Hierárquico está ativado para a conta. Este cabeçalho é suportado nas versões 2021-08-06 e posterior. |
x-ms-tags |
Opcional. Define as etiquetas codificadas de cadeia de consulta especificadas no blob. Para obter informações adicionais, consulte a secção Observações . Suportado na versão 2019-12-12 e posterior. |
x-ms-lease-id:<ID> |
Necessário se o blob tiver uma concessão ativa. Para efetuar esta operação num blob com uma concessão ativa, especifique o ID de concessão válido para este cabeçalho. |
x-ms-client-request-id |
Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos de análise quando o registo de análise de armazenamento é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. |
x-ms-blob-content-disposition |
Opcional. Define o cabeçalho do Content-Disposition 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 payload de resposta e pode ser utilizado para anexar metadados adicionais. Por exemplo, se estiver definido como attachment , este cabeçalho indica que o utilizador-agente não deve apresentar a resposta, mas deve mostrar uma caixa de diálogo Guardar Como.A resposta das operações Obter Propriedades do 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 o escalão a definir num blob. Para blobs de blocos, este cabeçalho é suportado em contas de armazenamento de blobs ou para fins gerais v2 apenas com a versão 2018-11-09 e posterior. Os valores válidos para as camadas de blob de blocos são Hot , Cool , Cold e Archive .
Nota: Cold o escalão é suportado para a versão 2021-12-02 e posterior. Para obter informações detalhadas sobre a camada de blobs de blocos, veja Camadas de armazenamento frequente, esporádico e de arquivo. |
x-ms-immutability-policy-until-date |
Versão 2020-06-12 e posterior. Especifica a data de retenção até ser definida no blob. Esta é a data até à qual o blob pode ser protegido contra modificação ou eliminaçã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 definir no blob. Os valores válidos são unlocked e locked . O unlocked valor indica que os utilizadores podem alterar a política ao aumentar ou diminuir a data de retenção até à data. O locked valor indica que estas ações são proibidas. |
x-ms-legal-hold |
Versão 2020-06-12 e posterior. Especifica a suspensão legal a definir 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 expiração do pedido, veja ExpiryOption. Este cabeçalho é válido para contas com o espaço de nomes hierárquico ativado. |
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 expiração varia de acordo x-ms-expiry-option com . Para obter mais informações, consulte ExpiryOption. Este cabeçalho é válido para contas com o espaço de nomes hierárquico ativado. O expiryTime já presente num blob não é limpo se o pedido não contiver um novo valor de expiryTime |
Esta operação também suporta a utilização de cabeçalhos condicionais para consolidar a lista de blocos apenas se for cumprida uma condição especificada. Para obter mais informações, veja Especificar cabeçalhos condicionais para operações de Armazenamento de Blobs.
Cabeçalhos de pedido (chaves de encriptação fornecidas pelo cliente)
A partir da versão 2019-02-02, pode especificar os seguintes cabeçalhos no pedido para encriptar um blob com uma chave fornecida pelo cliente. A encriptação com uma chave fornecida pelo cliente (e o conjunto de cabeçalhos correspondente) é opcional.
Cabeçalho do pedido | Description |
---|---|
x-ms-encryption-key |
Obrigatório. A chave de encriptação AES-256 codificada com Base64. |
x-ms-encryption-key-sha256 |
Obrigatório. O hash SHA256 codificado com Base64 da chave de encriptação. |
x-ms-encryption-algorithm: AES256 |
Obrigatório. Especifica o algoritmo a utilizar para encriptação. O valor deste cabeçalho tem de ser AES256 . |
Corpo do pedido
No corpo do pedido, pode especificar a lista de blocos que o Armazenamento de Blobs deve verificar para o bloco pedido. Desta forma, pode atualizar um blob existente ao inserir, substituir ou eliminar blocos individuais, em vez de recarregar todo o blob. Depois de carregar o bloco ou blocos que foram alterados, pode consolidar uma nova versão do blob ao consolidar os novos blocos juntamente com os blocos existentes que pretende manter.
Para atualizar um blob, pode especificar que o serviço deve procurar um ID de bloco na lista de blocos consolidado, na lista de blocos não comprometidos ou na lista de blocos não comprometidos primeiro e, em seguida, na lista de blocos consolidado. Para indicar que abordagem utilizar, especifique o ID de bloco que está dentro do elemento XML adequado no corpo do pedido, da seguinte forma:
Especifique o ID de bloco no elemento para indicar que o
Committed
Armazenamento de Blobs deve procurar apenas a lista de blocos consolidado para o bloco com nome. Se o bloco não for encontrado na lista de blocos consolidados, não será escrito como parte do blob e o Armazenamento de Blobs devolverá o código de estado 400 (Pedido Incorreto).Especifique o ID de bloco no elemento para indicar que o
Uncommitted
Armazenamento de Blobs deve procurar apenas a lista de blocos não comprometidos para o bloco com nome. Se o bloco não for encontrado na lista de blocos não comprometidos, não será escrito como parte do blob e o Armazenamento de Blobs devolve o código de estado 400 (Pedido Incorreto).Especifique o ID de bloco no elemento para indicar que o
Latest
Armazenamento de Blobs deve procurar primeiro na lista de blocos não comprometidos. Se o bloco for encontrado na lista não consolidada, essa versão do bloco é a mais recente e deve ser escrita no blob. Se o bloco não for encontrado na lista não consolidada, o serviço deverá procurar o bloco com nome na lista de blocos consolidados e escrever esse bloco no blob, se for encontrado.
O corpo do pedido para esta versão do Put Block List
utiliza 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>
Pedido de exemplo
Para demonstrar Put Block List
, suponha que carregou três blocos que pretende consolidar. O exemplo seguinte consolida um novo blob ao indicar que deve ser utilizada a versão mais recente de cada bloco listado. Não é necessário saber se estes blocos já foram consolidados.
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 pretende atualizar o blob. O novo blob tem as seguintes alterações:
Um novo bloco com o ID
ANAAAA==
. Primeiro, este bloco tem de ser carregado com uma chamada para Colocar Bloco e aparece na lista de blocos não comprometidos até à chamada paraPut Block List
.Uma versão atualizada do bloco com o ID
AZAAAA==
. Primeiro, este bloco tem de ser carregado com uma chamada para Colocar Bloco e aparece na lista de blocos não comprometidos até à chamada paraPut Block List
.Remoção do bloco com o ID
AAAAAA==
. Uma vez que este bloco não está incluído na chamada seguinte paraPut Block List
, o bloco é efetivamente removido do blob.
O exemplo seguinte 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 estado HTTP e um conjunto de cabeçalhos de resposta.
Código de estado
Uma operação bem-sucedida devolve o código de estado 201 (Criado).
Para obter mais informações sobre códigos de estado, veja Códigos de estado e de erro.
Cabeçalhos de resposta
A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão 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 etiqueta de entidade contém um valor que o cliente pode utilizar para realizar operações condicionais GET/PUT com o cabeçalho do If-Match pedido. Se a versão do pedido for 2011-08-18 ou posterior, o valor ETag estará entre aspas. |
Last-Modified |
A data/hora em que o blob foi modificado pela última vez. O formato de data segue RFC 1123. Para obter mais informações, veja Representar valores de data/hora em cabeçalhos. Qualquer operação que modifique o blob, incluindo uma atualização dos metadados ou propriedades do blob, altera a última hora modificada do blob. |
Content-MD5 |
Devolvido para que o cliente possa verificar a integridade do conteúdo da mensagem. Este cabeçalho refere-se ao conteúdo do pedido (neste caso, à lista de blocos e não ao conteúdo do próprio blob). Para a versão 2019-02-02 e posterior, este cabeçalho só é devolvido quando o pedido tiver este cabeçalho. |
x-ms-content-crc64 |
Para a versão 2019-02-02 e posterior, este cabeçalho é devolvido para que o cliente possa verificar a integridade do conteúdo da mensagem. Este cabeçalho refere-se ao conteúdo do pedido (neste caso, à lista de blocos e não ao conteúdo do próprio blob). Este cabeçalho é devolvido quando Content-md5 o cabeçalho não está presente no pedido. |
x-ms-request-id |
Identifica exclusivamente o pedido que foi feito e pode utilizá-lo para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API. |
x-ms-version |
A versão do Armazenamento de Blobs que é utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos efetuados 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 deste cabeçalho está definido como true se os conteúdos do pedido forem encriptados com êxito com o algoritmo especificado. Caso contrário, o valor está definido como false . |
x-ms-encryption-key-sha256 |
Versão 2019-02-02 e posterior. Este cabeçalho é devolvido se o pedido tiver utilizado uma chave fornecida pelo cliente para encriptação, para que o cliente possa garantir que os conteúdos do pedido são encriptados com êxito através da chave fornecida. |
x-ms-encryption-scope |
Versão 2019-02-02 e posterior. Este cabeçalho é devolvido se o pedido tiver utilizado um âmbito de encriptação, para que o cliente possa garantir que os conteúdos do pedido são encriptados com êxito através do âmbito de encriptação. |
x-ms-version-id: <DateTime> |
Versão 2019-12-12 e posterior. Devolve um valor opaco DateTime que identifica exclusivamente o blob. O valor deste cabeçalho indica a versão do blob e pode ser utilizado em pedidos subsequentes para aceder ao blob. |
x-ms-client-request-id |
Pode ser utilizado para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do x-ms-client-request-id cabeçalho se estiver presente no pedido e o valor não contiver mais de 1024 carateres ASCII visíveis. Se o x-ms-client-request-id cabeçalho não estiver presente no pedido, não está presente na resposta. |
Resposta de amostra
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. Pode autorizar a Put Block List
operação conforme descrito abaixo.
Se um pedido especificar etiquetas com o cabeçalho do x-ms-tags
pedido, o autor da chamada tem de cumprir os requisitos de autorização da operação Definir Etiquetas de Blobs .
Importante
A Microsoft recomenda a utilização de Microsoft Entra ID com identidades geridas para autorizar pedidos para o Armazenamento do Azure. Microsoft Entra ID fornece segurança e facilidade de utilização superiores em comparação com a autorização de Chave Partilhada.
O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos para dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.
Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.
Permissões
Abaixo estão listadas as ações RBAC necessárias para que um utilizador Microsoft Entra, grupo, identidade gerida ou principal de serviço chame a Put Block List
operação e a função RBAC do Azure com menos privilégios que inclua esta ação:
- Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Função incorporada com menos privilégios:Contribuidor de Dados de Blobs de Armazenamento
Para saber mais sobre como atribuir funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.
Observações
A Put Block List
operação impõe a ordem pela qual os blocos devem ser combinados para criar um blob.
O mesmo ID de bloco pode ser especificado mais do que uma vez na lista de blocos. Se um ID de bloco for especificado mais do que uma vez, representa o intervalo de bytes em cada uma dessas localizações na lista de blocos para o blob consolidado final. Se um ID de bloco aparecer mais do que uma vez na lista, ambas as instâncias do ID de bloco têm de ser especificadas na mesma lista de blocos. Por outras palavras, ambas as instâncias têm de ser especificadas no Committed
elemento, no Uncommitted
elemento ou no Latest
elemento.
Com Put Block List
o , pode modificar um blob existente ao inserir, atualizar ou eliminar blocos individuais sem ter de carregar o blob inteiro novamente. Pode especificar IDs de bloco a partir da lista de blocos consolidados atual e da lista de blocos não comprometidos para criar um novo blob ou atualizar o conteúdo de um blob existente. Desta forma, pode atualizar um blob ao especificar alguns novos blocos da lista de blocos não comprometidos e os restantes da lista de blocos consolidados, que já fazem parte do blob existente.
Se for especificado um ID de bloco no Latest
elemento e o mesmo ID de bloco existir nas listas de blocos consolidadas e não consolidadas, Put Block List
consolida o bloco a partir da lista de blocos não consolidado. Se o ID de bloco existir na lista de blocos consolidado, mas não na lista de blocos não comprometidos, Put Block List
consolida o bloco a partir da lista de blocos consolidado.
Cada bloco num blob de blocos pode ter um tamanho diferente. Um blob de blocos pode incluir um máximo de 50 000 blocos consolidados. O número máximo de blocos não comprometidos que podem estar associados a um blob é 100 000.
A tabela seguinte descreve os tamanhos máximos permitidos de blocos e blobs, 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 através de uma operação de escrita única (via Put Blob ) |
---|---|---|---|
Versão 2019-12-12 e posterior | 4000 mebibytes (MiB) | Aproximadamente 190,7 tebibytes (TiB) (4000 MiB × 50.000 blocos) | 5000 MiB |
Versões 2016-05-31 até 2019-07-07 | 100 MiB | Aproximadamente 4,75 TiB (100 MiB × 50 000 blocos) | 256 MiB |
Versões anteriores a 2016-05-31 | 4 MiB | Aproximadamente 195 GiB (4 MiB × 50.000 blocos) | 64 MiB |
Quando chama Put Block List
para atualizar um blob existente, as propriedades e metadados existentes do blob são substituídos. No entanto, todos os instantâneos existentes são retidos com o blob. Pode utilizar os cabeçalhos do pedido condicional para executar a operação apenas se uma condição especificada for cumprida.
Se a Put Block List
operação falhar devido a um bloco em falta, terá de carregar o bloco em falta.
Todos os blocos não consolidados são recolhidos da memória se não existirem chamadas bem-sucedidas para Put Block
ou Put Block List
para o blob no prazo de uma semana após a última operação bem-sucedida Put Block
. Se a função Colocar Blob for chamada no blob, todos os blocos não consolidados serão recolhidos da memória.
Se forem fornecidas etiquetas no x-ms-tags
cabeçalho, têm de ser codificadas com cadeia de consulta. As chaves de etiqueta e os valores têm de 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 etiquetas de até 2 KiB de tamanho. Se forem necessárias mais etiquetas, utilize a operação Definir Etiquetas de Blobs .
Se o blob tiver uma concessão ativa, o cliente tem de especificar um ID de concessão válido no pedido para consolidar a lista de blocos. Se o cliente não especificar um ID de concessão ou especificar um ID de concessão inválido, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição). Se o cliente especificar um ID de concessão, mas o blob não tiver uma concessão ativa, o Armazenamento de Blobs também devolve o código de estado 412 (Falha na Pré-condição). Se o cliente especificar um ID de concessão num blob que ainda não existe, o Armazenamento de Blobs devolve o código de estado 412 (Falha na Pré-condição) para pedidos feitos na versão 2013-08-15 ou posterior. Para versões anteriores, o Armazenamento de Blobs devolve o código de estado 201 (Criado).
Se o blob tiver uma concessão ativa e chamar Put Block List
para atualizar o blob, a concessão será mantida no blob atualizado.
Put Block List
aplica-se apenas a blobs de blocos. Chamar Put Block List
num blob de página resulta no código de estado 400 (Pedido Incorreto).
A substituição de um blob arquivado falha e a substituição de um hot
blob ou cool
herda a camada do blob antigo se o cabeçalho x-ms-access-tier não for fornecido.
Faturação
Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Put Block List
pedidos com base no tipo de conta de armazenamento:
Operação | Tipo de conta de armazenamento | Categoria de faturação |
---|---|---|
Put Block List | Blob de blocos Premium Standard para fins gerais v2 Standard para fins gerais v1 |
Operações de escrita |
Para saber mais sobre os preços da categoria de faturação especificada, veja Preços do Armazenamento de Blobs do Azure.
Ver também
Compreender blobs de blocos, blobs de acréscimo e blobs de páginas
Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro
Códigos de erro do serviço Blob
Definir tempos limite para operações do serviço Blob