VENDAS: 1-800-867-1389
Este artigo foi traduzido por máquina. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original.
Tradução
Original

Colocar lista de blocos

 

O Put Block List operação grava um blob especificando a lista de IDs que constituem o blob de bloco. Para ser gravado como parte de um blob, um bloco deve ter sido gravado com êxito o servidor em uma prévia Colocar Bloco operação.

Você pode chamar Put Block List para atualizar um blob Carregando apenas os blocos que foram alterados e depois confirmando os blocos novos e existentes juntos. Para fazer isso, especifique se um bloco deve ser confirmado da lista de blocos confirmados ou da lista de blocos não confirmados, ou confirme a versão mais recente carregada do bloco, independentemente da lista à qual ele pertença.

O Put Block List solicitação pode ser construída da seguinte maneira. HTTPS é recomendado. Substitua myaccount com o nome da sua conta de armazenamento:

URI de solicitação do método PUT

Versão de HTTP

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

HTTP/1.1

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

URI de solicitação do método PUT

Versão de HTTP

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

HTTP/1.1

Observe que o emulador de armazenamento oferece suporte apenas a tamanhos de blob de até 2 GB.

Para obter mais informações, consulte usando o emulador de armazenamento do Azure para desenvolvimento e teste.

Os seguintes parâmetros adicionais podem ser especificados no URI de solicitação.

PARAMETER

Descrição

timeout

Opcional. O timeout parâmetro é expresso em segundos. Para obter mais informações, consulte Configurando os tempos limite para operações de serviço do Blob.

A tabela a seguir descreve os cabeçalhos de solicitação obrigatórios e opcionais.

Cabeçalho de solicitação

Descrição

Authorization

Obrigatório. Especifica o esquema de autenticação, o nome da conta e a assinatura. Para obter mais informações, consulte Autenticação federada para os Serviços de Armazenamento do Azure.

Date ou x-ms-date

Obrigatório. Especifica o Tempo Universal Coordenado (UTC) para a solicitação. Para obter mais informações, consulte Autenticação federada para os Serviços de Armazenamento do Azure.

x-ms-version

Obrigatório para todas as solicitações autenticadas. 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ório. O comprimento do conteúdo da solicitação em bytes. Observe que esse cabeçalho se refere ao comprimento do conteúdo da lista de blocos, não do próprio blob.

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 Incorreta).

Observe que esse cabeçalho está associado ao conteúdo da solicitação, e não ao conteúdo do próprio blob.

x-ms-blob-cache-control

Opcional. Define o controle de cache do blob. Se especificada, essa propriedade será armazenada com o blob e retornada com uma solicitação de leitura.

Se essa propriedade não for especificada com a solicitação, será apagada 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 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 de padrão, que é application/octet-stream.

x-ms-blob-content-encoding

Opcional. Define a codificação do conteúdo do blob. Se especificada, essa propriedade será armazenada com o blob e retornada com uma solicitação de leitura.

Se essa propriedade não for especificada com a solicitação, será apagada para o blob se a solicitação for bem-sucedida.

x-ms-blob-content-language

Opcional. Defina o idioma do conteúdo do blob. Se especificada, essa propriedade será armazenada com o blob e retornada com uma solicitação de leitura.

essa propriedade não for especificada com a solicitação, será apagada para o blob se a solicitação for bem-sucedida.

x-ms-blob-content-md5

Opcional. Um hash MD5 do conteúdo do blob. Observe que esse hash não está validado, pois os hashes dos blocos individuais foram validados quando cada um deles foi carregado.

O Obter Blob operação retorna o valor desse cabeçalho no cabeçalho de resposta Content-MD5.

Se essa propriedade não for especificada com a solicitação, será apagada para o blob se a solicitação for bem-sucedida.

x-ms-meta-name:value

Opcional. Pares de nome-valor definidos pelo usuário associados ao blob.

Observe que a partir da versão 2009-09-19, os nomes de metadados devem aderir às regras de nomenclatura para identificadores c#.

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 limite de caractere de 1 KB que será registrado nos logs de análise quando o registro em log da análise de armazenamento for habilitado. O uso desse cabeçalho é altamente recomendável para correlacionar atividades do lado do cliente com solicitações recebidas pelo servidor. Para obter mais informações, consulte Sobre o log de análise de armazenamento e log do Azure: Usando Logs para rastrear solicitações de armazenamento.

x-ms-blob-content-disposition

Opcional. Define o blob Content-Disposition cabeçalho. Disponível para versões 2013-08-15 e posteriores.

O Content-Disposition campo de cabeçalho transmite informações adicionais sobre como processar a carga de resposta e também pode ser usado para anexar metadados adicionais. Por exemplo, se definido como attachment, ele indica que o agente do usuário não deve exibir a resposta, mas em vez disso, mostrar uma caixa de diálogo Salvar como.

A resposta da Obter Blob e Obter propriedades de blob operações inclui o cabeçalho content-disposition.

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 Especificando cabeçalhos condicionais para operações de serviço Blob.

No corpo da solicitação, você pode especificar em qual lista de blocos o serviço Blob deverá procurar o bloco solicitado. Desse modo, você pode atualizar um blob existente inserindo, substituindo ou excluindo blocos individuais, em vez de recarregar todo o blob. Após o carregamento dos blocos que foram alterados, você poderá confirmar uma nova versão do blob ao confirmar os novos blocos em conjunto 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 o método a ser usado, especifique a ID do bloco dentro do elemento XML apropriado dentro do corpo da solicitação, da seguinte forma:

  • Especifique a ID de bloco no Committed elemento para indicar que o serviço Blob deve pesquisar somente 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 serviço Blob retornará o código de status 400 (Solicitação Incorreta).

  • Especifique a ID de bloco no Uncommitted elemento para indicar que o serviço Blob deve pesquisar somente 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 serviço Blob retornará o código de status 400 (Solicitação Incorreta).

  • Especifique a ID de bloco no Latest elemento para indicar que o serviço Blob deve pesquisar primeiro 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 localizado na lista de não confirmados, o serviço deverá pesquisar a lista de blocos confirmados para o bloco indicado e gravar esse bloco no blob, se 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>

Para demonstrar Put Block List, suponha que você carregou 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ê queira atualizar o blob. O novo blob terá as seguintes alterações:

  • Um novo bloco com ID ANAAAA==. Este bloco deve primeiro ser carregado com uma chamada para Colocar Bloco e aparecerá na lista de blocos não confirmados até a chamada para Put Block List.

  • Uma versão atualizada do bloco com ID AZAAAA==. Este bloco deve primeiro ser carregado com uma chamada para Colocar Bloco e aparecerá na lista de blocos não confirmados até a chamada para Put Block List.

  • Remoção do bloco com a identificação AAAAAA==. Considerando que este bloco não está incluído na próxima chamada para Put Block List, o bloco será 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 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>

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

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

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

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 obedecem a especificação de protocolo HTTP/1.1.

Resposta

Descrições

ETag

A tag de entidade contém um valor que o cliente pode usar para executar condicional GET/PUT operações usando o If-Match cabeçalho da solicitação. Se a versão da solicitação for a 2011-08-18 ou mais recente, o valor de ETag será exibido 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 Representação de 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

Esse cabeçalho é retornado para que o cliente possa verificar a integridade do conteúdo da mensagem. Esse cabeçalho se refere ao conteúdo da solicitação, ou seja, nesse caso, a lista de blocos, e não ao conteúdo do próprio blob.

x-ms-request-id

Esse cabeçalho identifica a solicitação que foi feita de forma exclusiva e pode ser usado para solucionar problemas na solicitação. Para obter mais informações, consulte Solucionando problemas nas operações de API.

x-ms-version

Indica a versão do serviço Blob usado para executar a solicitação. Esse cabeçalho é retornado para solicitações feitas na versão 2009-09-19 e mais recente.

Date

Um valor de data/hora UTC gerado pelo serviço que indica a hora em que a resposta foi iniciada.

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

Essa operação poderá ser chamada pelo proprietário da conta e por qualquer pessoa com uma assinatura de acesso compartilhado que tenha permissão para gravar nesse blob ou em seu contêiner.

O Put Block List operação impõe a ordem na qual 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, isso representará o intervalo de bytes em cada um desses locais na lista de blocos do 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. Em outras palavras, as duas instâncias devem ser especificadas dentro do Committed elemento, o Uncommitted elemento, ou o Latest elemento.

Com Put Block List, você pode modificar um blob existente inserindo, atualizando, ou excluindo blocos individuais, sem carregar todo o blob 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. Desse modo você pode atualizar um blob especificando alguns novos blocos da lista de blocos não confirmados, e o restante da lista de contatos bloqueados confirmada, que já fazem parte do blob existente.

Se for especificada uma ID de bloco na Latest elemento e o mesmo bloco de ID existe em ambas as listas de blocos confirmados e não confirmados, 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 blocos não confirmados, em seguida, Put Block List confirmará o bloco da lista de blocos confirmados.

Cada bloco pode ter um tamanho diferente, até um máximo de 4 MB, e um blob de bloco pode incluir um máximo de 50.000 blocos. O tamanho máximo de um blob de bloco, portanto, é um pouco mais de 195 GB (4 MB X 50.000 blocos). Se você tentar confirmar mais de 50.000 blocos, o serviço retornará o código de status 413 (Entidade de Solicitação Muito Grande). O serviço também retorna informações adicionais sobre o erro na resposta, inclusive o número máximo permitido de blocos.

O número máximo de blocos não confirmados que pode ser associado a um blob é 100.000, e o tamanho máximo da lista de blocos não confirmados é 400 GB.

Quando você chama Put Block List para atualizar um blob existente, as propriedades existentes e os metadados do 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 o Put Block List operação falha devido a um bloco ausente, você precisará carregar o bloco ausente.

Todos os blocos não confirmados serão limpos se não houver nenhuma chamada bem-sucedida a Put Block ou Put Block List no blob dentro de uma semana após a última bem-sucedida Put Block operação. Se Colocar Blob é chamado no blob, todos os blocos não confirmados serão limpos.

Se o blob tiver uma concessão ativa, o cliente deverá especificar uma ID de concessão válida para confirmar a lista de blocos. Se o cliente não especificar uma ID de concessão ou especificar uma ID inválida, o serviço Blob retornará o código de status 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 serviço Blob também retornará o código de status 412 (Falha na Pré-condição). Se o cliente especificar um ID de concessão em um blob que ainda não existir, o serviço Blob retornará o código de status 412 (falha na pré-condição) para solicitações feitas na versão 2013-08-15 e posterior; para versões anteriores, o serviço Blob retornará o código de status 201 (criado).

Se o blob tiver uma concessão ativa e chame Put Block List para atualizar o blob, a concessão é mantida no blob atualizado.

Put Block List aplica-se apenas a blobs de bloco. Chamando Put Block List em um blob de páginas resulta no status de código 400 (solicitação incorreta).

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2016 Microsoft