Put Block List (Вставка списка блокировки)

Статья
03/16/2023

Операция Put Block List записывает большой двоичный объект, указывая список составляющих его блочных идентификаторов. Для записи в составе большого двоичного объекта блок должен быть успешно записан на сервер в ходе предыдущей операции Put Block .

Вы можете вызвать метод Put Block List для обновления большого двоичного объекта, отправив только те блоки, которые были изменены, а затем зафиксировав новые и существующие блоки вместе. Это можно сделать, указав, следует ли зафиксировать блок из списка зафиксированных блокировок или из незафиксированного списка блоков или зафиксировать самую последнюю отправленную версию блока, в зависимости от того, к какому списку он принадлежит.

Запрос

Запрос можно создать Put Block List следующим образом. Рекомендуется использовать ПРОТОКОЛ HTTPS. Замените myaccount именем своей учетной записи хранения:

URI запроса метода PUT	параметр "Версия HTTP"
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Запрос службы эмулированного хранилища

При выполнении запроса к эмулированной службе хранилища укажите имя узла эмулятора и порт службы BLOB-объектов в качестве 127.0.0.1:10000, а затем имя эмулированной учетной записи хранения:

URI запроса метода PUT	параметр "Версия HTTP"
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Эмулятор хранения поддерживает только большие двоичные объекты размером до 2 ГиБ.

Дополнительные сведения см. в статье Использование эмулятора Azurite для разработки и тестирования службы хранилища Azure.

Параметры универсального кода ресурса (URI)

В запросе URI можно указать следующие дополнительные параметры.

Параметр	Описание
`timeout`	Необязательный элемент. Параметр `timeout` указывается в секундах. Дополнительные сведения см. в разделе Настройка времени ожидания для операций службы BLOB-объектов.

Заголовки запросов

Обязательные и необязательные заголовки запросов описаны в следующей таблице:

Заголовок запроса	Описание
`Authorization`	Обязательный. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure.
`Date` или `x-ms-date`	Обязательный. Задает время запроса в формате UTC. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure.
`x-ms-version`	Требуется для всех авторизованных запросов. Задает версию операции, используемой для этого запроса. Дополнительные сведения см. в разделе Управление версиями для служб хранилища Azure.
`Content-Length`	Обязательный. Длина содержимого запроса в байтах. Этот заголовок ссылается на длину содержимого списка блоков, а не самого большого двоичного объекта.
`Content-MD5`	Необязательный элемент. Хэш MD5 содержимого запроса. Этот хэш используется для проверки целостности содержимого запроса в ходе транспортировки. Если два хэша не совпадают, операция завершается ошибкой с кодом 400 (недопустимый запрос). Этот заголовок связан с содержимым запроса, а не с содержимым самого большого двоичного объекта.
`x-ms-content-crc64`	Необязательный элемент. Хэш CRC64 содержимого запроса. Этот хэш используется для проверки целостности содержимого запроса в ходе транспортировки. Если два хэша не совпадают, операция завершается ошибкой с кодом 400 (недопустимый запрос). Этот заголовок связан с содержимым запроса, а не с содержимым самого большого двоичного объекта. Если присутствуют заголовки Content-MD5 и x-ms-content-crc64, запрос завершается ошибкой 400 (недопустимый запрос). Этот заголовок поддерживается в версии 2019-02-02 и более поздних версиях.
`x-ms-blob-cache-control`	Необязательный элемент. Задает управление кэшем большого двоичного объекта. Если это свойство указано, оно сохраняется в большом двоичном объекте и возвращается с запросом на чтение. Если свойство не указано в запросе, оно очищается для большого двоичного объекта при успешном выполнении запроса.
`x-ms-blob-content-type`	Необязательный элемент. Задает тип содержимого большого двоичного объекта. Если оно указано, это свойство сохраняется в большом двоичном объекте и возвращается с запросом на чтение. Если тип контента не указан, ему присваивается тип по умолчанию, то есть `application/octet-stream`.
`x-ms-blob-content-encoding`	Необязательный элемент. Задает кодировку содержимого большого двоичного объекта. Если оно указано, это свойство сохраняется в большом двоичном объекте и возвращается с запросом на чтение. Если свойство не указано в запросе, оно очищается для большого двоичного объекта при успешном выполнении запроса.
`x-ms-blob-content-language`	Необязательный элемент. Задает язык содержимого BLOB-объекта. Если оно указано, это свойство сохраняется в большом двоичном объекте и возвращается с запросом на чтение. Если свойство не указано в запросе, оно очищается для большого двоичного объекта при успешном выполнении запроса.
`x-ms-blob-content-md5`	Необязательный элемент. Хэш MD5 содержимого большого двоичного объекта. Этот хэш не проверяется, так как хэши для отдельных блоков проверялись при отправке каждого из них. Операция Получения BLOB-объекта возвращает значение этого заголовка в заголовке ответа Content-MD5. Если это свойство не указано в запросе, оно очищается для большого двоичного объекта в случае успешного выполнения запроса.
`x-ms-meta-name:value`	Необязательный элемент. Определяемые пользователем пары "имя-значение", связанные с большим двоичным объектом. Начиная с версии 2009-09-19 имена метаданных должны соответствовать правилам именования для идентификаторов C#.
`x-ms-encryption-scope`	Необязательный элемент. Указывает область шифрования для шифрования большого двоичного объекта. Это значение должно соответствовать область шифрования, используемому для шифрования всех блоков, которые фиксируются. Этот заголовок поддерживается в версии 2019-02-02 и более поздних версиях.
`x-ms-encryption-context`	Необязательный элемент. Значение по умолчанию — "Пустой". Если значение задано, будут заданы метаданные системы BLOB-объектов. Максимальная длина — 1024. Допустимо, только если для учетной записи включено иерархическое пространство имен. Этот заголовок поддерживается в версиях 2021-08-06 и более поздних.
`x-ms-tags`	Необязательный элемент. Задает указанные теги в кодировке строки запроса в большом двоичном объекте. Дополнительные сведения см. в разделе Примечания . Поддерживается в версии 2019-12-12 и более поздних версиях.
`x-ms-lease-id:<ID>`	Требуется, если у большого двоичного объекта имеется активная аренда. Для выполнения этой операции в большом двоичном объекте с активной арендой укажите допустимый идентификатор аренды для этого заголовка.
`x-ms-client-request-id`	Необязательный элемент. Предоставляет созданное клиентом непрозрачное значение с ограничением в 1 кибибайт (КиБ), которое записывается в журналы аналитики при настройке ведения журнала аналитики хранилища. Мы настоятельно рекомендуем использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером.
`x-ms-blob-content-disposition`	Необязательный элемент. Задает заголовок `Content-Disposition` большого двоичного объекта. Доступно для версии 2013-08-15 и более поздних версий. Поле `Content-Disposition` заголовка содержит дополнительные сведения о том, как обрабатывать полезные данные ответа, и его можно использовать для вложения дополнительных метаданных. Например, если задано значение `attachment`, этот заголовок указывает, что агент пользователя не должен отображать ответ, а должен отображать диалоговое окно Сохранить как. Ответ от операций Получить BLOB-объект и Получить свойства BLOB-объекта включает заголовок content-disposition.
`x-ms-access-tier`	Необязательный элемент. Версия 2018-11-09 и более поздняя. Указывает уровень для большого двоичного объекта. Для блочных BLOB-объектов этот заголовок поддерживается в хранилище BLOB-объектов или учетных записях общего назначения версии 2 только с версии 2018-11-09 и более поздних версий. Допустимые значения для уровней блочных BLOB-объектов: `Hot`, `Cool`, `Cold`и `Archive`. Примечание. `Cold` Уровень поддерживается для версии 2021-12-02 и более поздних версий. Подробные сведения о разных уровнях блочных BLOB-объектов см. в разделе Горячий, холодный и архивный уровни хранилища.
`x-ms-immutability-policy-until-date`	Версия 12.06.2020 и более поздняя. Указывает дату хранения до установки для большого двоичного объекта. Это дата, до которой blob-объект можно защитить от изменения или удаления. Соответствует формату RFC1123.
`x-ms-immutability-policy-mode`	Версия 12.06.2020 и более поздняя. Указывает режим политики неизменности, который необходимо задать для большого двоичного объекта. Допустимые значения: `unlocked` и `locked`. Значение `unlocked` указывает, что пользователи могут изменить политику путем увеличения или уменьшения срока хранения до даты. Значение `locked` указывает, что эти действия запрещены.
`x-ms-legal-hold`	Версия 12.06.2020 и более поздняя. Указывает удержание по юридическим причинам для большого двоичного объекта. Возможные значения: `true` и `false`.
`x-ms-expiry-option`	Необязательный элемент. Версия 2023-08-03 и более поздняя. Указывает параметр даты окончания срока действия для запроса, см. раздел ExpiryOption. Этот заголовок допустим для учетных записей с включенным иерархическим пространством имен.
`x-ms-expiry-time`	Необязательный элемент. Версия 2023-08-03 и более поздняя. Указывает время истечения срока действия BLOB-объекта. Формат даты окончания срока действия зависит от `x-ms-expiry-option`. Дополнительные сведения см. в разделе ExpiryOption. Этот заголовок допустим для учетных записей с включенным иерархическим пространством имен. Уже присутствующий `expiryTime` в большом двоичном объекте не очищается, если запрос не содержит новое значение `expiryTime`

Эта операция также поддерживает использование условных заголовков только для фиксации списка блокировок и только в случае, если выполняются указанные условия. Дополнительные сведения см. в разделе Указание условных заголовков для операций с хранилищем BLOB-объектов.

Заголовки запросов (ключи шифрования, предоставленные клиентом)

Начиная с версии 2019-02-02 вы можете указать следующие заголовки в запросе на шифрование БОЛЬШОГО ДВОИЧНОГО ОБЪЕКТА с помощью ключа, предоставленного клиентом. Шифрование с помощью предоставленного клиентом ключа (и соответствующего набора заголовков) является необязательным.

Заголовок запроса	Описание
`x-ms-encryption-key`	Обязательный. Ключ шифрования AES-256 в кодировке Base64.
`x-ms-encryption-key-sha256`	Обязательный. Хэш SHA256 ключа шифрования в кодировке Base64.
`x-ms-encryption-algorithm: AES256`	Обязательный. Указывает алгоритм, используемый для шифрования. Для этого заголовка должно быть установлено значение `AES256`.

Текст запроса

В тексте запроса можно указать список блокировок, который хранилище BLOB-объектов должно проверка для запрошенного блока. Таким образом, можно обновить существующий BLOB-объект, вставляя, заменяя или удаляя отдельные блоки, а не перезагружая весь большой двоичный объект. После отправки измененных блоков можно зафиксировать новую версию большого двоичного объекта, зафиксировав новые блоки вместе с существующими блоками, которые вы хотите сохранить.

Чтобы обновить большой двоичный объект, можно указать, что служба должна искать идентификатор блокировки в списке зафиксированных блокировок, в списке незафиксированных блокировок либо в сначала в списке незафиксированных, а затем в списке зафиксированных блокировок. Чтобы указать, какой подход следует использовать, укажите идентификатор блока, который находится в соответствующем XML-элементе в тексте запроса, следующим образом:

Укажите идентификатор блока в элементе Committed , чтобы указать, что хранилище BLOB-объектов должно искать именованный блок только в списке зафиксированных блоков. Если блок не найден в списке зафиксированных блоков, он не записывается как часть большого двоичного объекта, а хранилище BLOB-объектов возвращает код состояния 400 (недопустимый запрос).
Укажите идентификатор блока в элементе Uncommitted , чтобы указать, что хранилище BLOB-объектов должно искать именованный блок только в списке незафиксированных блоков. Если блок не найден в списке незафиксированных блоков, он не записывается как часть большого двоичного объекта, а хранилище BLOB-объектов возвращает код состояния 400 (недопустимый запрос).
Укажите идентификатор блока в элементе Latest , чтобы указать, что хранилище BLOB-объектов должно сначала выполнить поиск в незафиксированный список блоков. Если блокировка найдена в списке незафиксированных, ее версия является последней и должна быть записана в большой двоичный объект. Если блок не найден в списке незафиксированных, служба должна выполнить поиск в списке зафиксированных блоков для именованного блока и записать этот блок в большой двоичный объект, если он найден.

Текст запроса для этой версии Put Block List использует следующий формат 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>

Пример запроса

Чтобы продемонстрировать Put Block List, предположим, что вы отправили три блока, которые вы хотите зафиксировать. В следующем примере новый большой двоичный объект фиксируется путем указания того, что должна использоваться последняя версия каждой блокировки в списке. Не нужно знать, зафиксированы ли уже эти блокировки на данный момент.

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>

Далее предположим, что вы хотите обновить большой двоичный объект. В новый BLOB-объект внесены следующие изменения:

Новая блокировка с идентификатором ANAAAA==. Этот блок должен быть сначала отправлен с вызовом Put Block, и он отображается в списке незафиксированных блокировок до вызова Put Block Listметода .
Обновленная версия блокировки с идентификатором AZAAAA==. Этот блок должен быть сначала отправлен с вызовом Put Block, и он отображается в списке незафиксированных блокировок до вызова Put Block Listметода .
Удаление блокировки с идентификатором AAAAAA==. Так как этот блок не включается в следующий вызов Put Block List, блок фактически удаляется из большого двоичного объекта.

В следующем примере показан вызов Put Block List, обновляющий большой двоичный объект.

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>

Ответ

Ответ включает код состояния HTTP и набор заголовков ответа.

Код состояния

Успешная операция возвращает код состояния 201 (создано).

Дополнительные сведения о кодах состояния см. в разделе Коды состояния и ошибок.

Заголовки ответов

Ответ для этой операции включает следующие заголовки. Ответ может также включать дополнительные стандартные заголовки HTTP. Все стандартные заголовки соответствуют спецификации протокола HTTP/1.1.

Ответ	Описания
`ETag`	Тег сущности содержит значение, которое клиент может использовать для выполнения условных операций `GET/PUT` с помощью заголовка запроса `If-Match`. Если версия запроса — 2011-08-18 или более поздняя, значение ETag заключается в кавычки.
`Last-Modified`	Дата и время последнего изменения BLOB-объекта. Дата в формате согласно RFC 1123. Дополнительные сведения см. в разделе Представление значений даты и времени в заголовках. Любая операция, которая изменяет BLOB-объект, в том числе обновление метаданных или свойств BLOB-объекта, изменяет время последнего изменения BLOB-объекта.
`Content-MD5`	Возвращается, чтобы клиент проверка для целостности содержимого сообщения. Этот заголовок ссылается на содержимое запроса (в данном случае это список блоков, а не содержимое самого большого двоичного объекта). Для версии 2019-02-02 и более поздних этот заголовок возвращается только в том случае, если запрос содержит этот заголовок.
`x-ms-content-crc64`	Для версии 2019-02-02 и более поздних этот заголовок возвращается, чтобы клиент проверка целостности содержимого сообщения. Этот заголовок ссылается на содержимое запроса (в данном случае это список блоков, а не содержимое самого большого двоичного объекта). Этот заголовок возвращается, если `Content-md5` заголовок отсутствует в запросе.
`x-ms-request-id`	Уникально идентифицирует выполненный запрос, и его можно использовать для устранения неполадок с запросом. Дополнительные сведения см. в статье Устранение неполадок с операциями API.
`x-ms-version`	Версия хранилища BLOB-объектов, используемая для выполнения запроса. Этот заголовок возвращается для запросов, выполненных в отношении версии 2009-09-19 и более поздних версий.
`Date`	Значение даты и времени в формате UTC, созданное службой, которое указывает, когда был инициирован ответ.
`x-ms-request-server-encrypted: true/false`	Версия 11.12.2015 и более поздняя. Если содержимое запроса успешно зашифровано с помощью указанного алгоритма, задается значение этого `true` заголовка. В противном случае задается значение `false`.
`x-ms-encryption-key-sha256`	Версия 2019-02-02 и более поздние версии. Этот заголовок возвращается, если запрос использовал предоставленный клиентом ключ для шифрования, чтобы клиент смог убедиться, что содержимое запроса успешно зашифровано с помощью предоставленного ключа.
`x-ms-encryption-scope`	Версия 2019-02-02 и более поздние версии. Этот заголовок возвращается, если запрос использовал область шифрования, поэтому клиент может убедиться, что содержимое запроса успешно зашифровано с помощью область шифрования.
`x-ms-version-id: <DateTime>`	Версия 12.12.2019 и более поздняя. Возвращает непрозрачное `DateTime` значение, однозначно определяющее большой двоичный объект. Значение этого заголовка указывает версию большого двоичного объекта, и его можно использовать в последующих запросах для доступа к большому двоичному объекту.
`x-ms-client-request-id`	Можно использовать для устранения неполадок с запросами и соответствующими ответами. Значение этого заголовка равно значению заголовка `x-ms-client-request-id` , если он присутствует в запросе и содержит не более 1024 видимых символов ASCII. Если заголовок `x-ms-client-request-id` отсутствует в запросе, он отсутствует в ответе.

Пример ответа

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>

Авторизация

Авторизация требуется при вызове любой операции доступа к данным в службе хранилища Azure. Вы можете авторизовать операцию, Put Block List как описано ниже.

Если в запросе указываются теги с заголовком x-ms-tags запроса, вызывающий объект должен соответствовать требованиям авторизации операции "Задать теги BLOB-объектов ".

Важно!

Корпорация Майкрософт рекомендует использовать Microsoft Entra ID с управляемыми удостоверениями для авторизации запросов к службе хранилища Azure. Microsoft Entra ID обеспечивает более высокий уровень безопасности и простоту использования по сравнению с авторизацией с общим ключом.

Служба хранилища Azure поддерживает использование Microsoft Entra ID для авторизации запросов к данным BLOB-объектов. С помощью Microsoft Entra ID можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности. Субъектом безопасности может быть пользователь, группа, субъект-служба приложения или управляемое удостоверение Azure. Субъект безопасности проходит проверку подлинности Microsoft Entra ID для возврата маркера OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе BLOB-объектов.

Дополнительные сведения об авторизации с помощью Microsoft Entra ID см. в статье Авторизация доступа к BLOB-объектам с помощью Microsoft Entra ID.

Разрешения

Ниже перечислены действия RBAC, необходимые Microsoft Entra пользователю, группе, управляемому удостоверению или субъекту-службе для вызова Put Block List операции, а также встроенная роль Azure RBAC с минимальными привилегиями, которая включает это действие.

Действие Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Встроенная роль с минимальными привилегиями:Участник данных BLOB-объектов хранилища

Дополнительные сведения о назначении ролей с помощью Azure RBAC см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.

Подписанный URL-адрес (SAS) обеспечивает безопасный делегированный доступ к ресурсам в учетной записи хранения. С помощью SAS вы можете детально контролировать доступ клиента к данным. Вы можете указать, к какому ресурсу может обращаться клиент, какие у него есть разрешения для этих ресурсов и как долго будет действителен SAS.

Операция Put Block List поддерживает три типа подписанных URL-адресов: SAS делегирования пользователей, SAS службы и SAS учетной записи.

В целях обеспечения безопасности рекомендуется использовать Microsoft Entra учетные данные, а не ключ учетной записи хранения, который проще скомпрометировать. Если для проектирования приложения требуются подписанные URL-адреса, по возможности используйте учетные данные Microsoft Entra, чтобы создать SAS для делегирования пользователей.

Если доступ к общему ключу запрещен для учетной записи хранения, маркер SAS службы или маркер SAS учетной записи не будет разрешен при запросе к хранилищу BLOB-объектов. Дополнительные сведения см. в статье Сведения о том, как запрет общего ключа влияет на маркеры SAS.

SAS для делегирования пользователей

SAS для делегирования пользователей защищен Microsoft Entra учетными данными, а также разрешениями, указанными для SAS.

Put Block List Для вызова операции с использованием маркера SAS, делегированного контейнеру или ресурсу BLOB-объекта, требуется разрешение на запись (w) в составе маркера SAS делегирования пользователей.

Дополнительные сведения о SAS для делегирования пользователей см. в статье Create SAS делегирования пользователей.

SAS для службы

SAS для службы защищен с помощью ключа учетной записи хранения. SAS службы делегирует доступ к ресурсу в одной службе хранилища Azure, например в хранилище BLOB-объектов.

Дополнительные сведения о SAS службы см. в статье Create SAS службы.

SAS для учетной записи

SAS для учетной записи защищен с помощью ключа учетной записи хранения. SAS учетной записи делегирует доступ к ресурсам в одной или нескольких службах хранилища. Все операции, доступные через SAS для службы или делегирования пользователей, также доступны через SAS для учетной записи.

В следующей таблице указаны подписанный тип ресурса и подписанные разрешения, которые необходимо указать при делегировании доступа:

Операция	Подписанная служба	Подписанный тип ресурса	Подписанное разрешение
Put Block List (Вставка списка блокировки)	Большой двоичный объект (b)	Объект (o)	Запись (w)

Дополнительные сведения о SAS учетной записи см. в статье Create SAS учетной записи.

Операция Put Block List поддерживает авторизацию с общим ключом. Авторизация с помощью ключей учетной записи не рекомендуется в большинстве сценариев, так как она менее безопасна.

Корпорация Майкрософт рекомендует запретить авторизацию с общим ключом для учетной записи хранения, когда это возможно. Дополнительные сведения см. в статье Предотвращение авторизации с помощью общего ключа.

Один идентификатор блокировки можно указать несколько раз в списке блокировок. Если идентификатор блока указан несколько раз, он представляет диапазон байтов в каждом из этих расположений в списке блоков для окончательного зафиксированного большого двоичного объекта. Если идентификатор блокировки встречается в списке несколько раз, оба экземпляра идентификатора блокировки должны быть указаны в одном списке блокировок. Другими словами, оба экземпляра должны быть указаны элементе Committed, элементе Uncommitted или элементе Latest.

С помощью Put Block Listможно изменить существующий BLOB-объект, вставляя, обновляя или удаляя отдельные блоки без необходимости повторной отправки всего большого двоичного объекта. Можно указывать идентификаторы блокировок и из текущего списка зафиксированных блокировок и из списка незафиксированных блокировок для создания нового большого двоичного объекта или обновления содержимого существующего объекта. Таким образом можно обновить большой двоичный объект, указав несколько новых блоков из списка незафиксированных блокировок, а остальные — из списка зафиксированных блоков, которые уже являются частью существующего большого двоичного объекта.

Если идентификатор блокировки указан в элементе Latest и один идентификатор блокировки есть в списке как зафиксированных, так и незафиксированных блокировок, операция Put Block List фиксирует блокировку из списка незафиксированных блокировок. Если идентификатор блока существует в списке зафиксированных блокировок, но не в списке незафиксированных блоков, Put Block List блок фиксируется из списка зафиксированных блоков.

Каждый блок в блочном BLOB-объекте может иметь разный размер. Блочный BLOB-объект может содержать не более 50 000 зафиксированных блоков. Максимальное число незафиксированных блоков, которые могут быть связаны с большим двоичным объектом, составляет 100 000.

В следующей таблице описаны максимальные допустимые размеры блоков и BLOB-объектов по версии службы.

Версия службы	Максимальный размер блока (с помощью `Put Block`)	Максимальный размер большого двоичного объекта (через `Put Block List`)	Максимальный размер большого двоичного объекта за счет одной операции записи (с помощью `Put Blob`)
Версия 2019-12-12 и более поздние	4000 мебибайт (МиБ)	Приблизительно 190,7 тбибайт (ТиБ) (4000 МиБ × 50 000 блоков)	5000 МиБ
Версии с 31.05.2016 по 07.07.2019	100 МиБ	Приблизительно 4,75 ТиБ (100 МиБ × 50 000 блоков)	256 МиБ
Версии, предшествующие 31.05.2016	4 МиБ	Приблизительно 195 ГиБ (4 МиБ × 50 000 блоков)	64 МиБ

При вызове Put Block List для обновления существующего большого двоичного объекта имеющиеся свойства и метаданные объекта перезаписываются. Однако все существующие моментальные снимки сохраняются с объектом. Можно использовать условные заголовки запросов для выполнения операции только при выполнении определенного условия.

Если операция завершается Put Block List сбоем из-за отсутствия блока, необходимо отправить отсутствующий блок.

Все незафиксированные блоки собираются в случае отсутствия успешных вызовов к большому двоичному объекту Put Block или Put Block List в течение недели после последней успешной Put Block операции. При вызове метода Put BLOB-объекта все незафиксированные блоки собирают мусор.

Если в заголовке x-ms-tags указаны теги, они должны быть закодированы в строке запроса. Ключи и значения тегов должны соответствовать требованиям к именованию и длине, как указано в Set Blob Tags. Кроме того, заголовок x-ms-tags может содержать теги размером до 2 КиБ. Если требуется больше тегов, используйте операцию Задать теги BLOB-объектов .

Если большой двоичный объект имеет активную аренду, клиент должен указать действительный идентификатор аренды в запросе на фиксацию списка блокировок. Если клиент не указывает идентификатор аренды или задает недопустимый идентификатор аренды, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия). Если клиент указывает идентификатор аренды, но большой двоичный объект не имеет активной аренды, хранилище BLOB-объектов также возвращает код состояния 412 (сбой предварительного условия). Если клиент указывает идентификатор аренды для большого двоичного объекта, который еще не существует, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия) для запросов, выполненных в отношении версии 2013-08-15 или более поздней. Для более ранних версий Хранилище BLOB-объектов возвращает код состояния 201 (создано).

Если большой двоичный объект имеет активную аренду и вы вызываете Put Block List для обновления большого двоичного объекта, то аренда сохраняется для переданного большого двоичного объекта.

Put Block List относится только к блочным BLOB-объектам. Вызов Put Block List для страничного BLOB-объекта вызывает код состояния 400 (неправильный запрос).

Перезапись архивного BLOB-объекта завершается сбоем, а перезапись большого hot двоичного объекта или cool наследует уровень от старого BLOB-объекта, если заголовок x-ms-access-tier не указан.

Выставление счетов

Запросы на ценообразование могут исходить от клиентов, использующих API хранилища BLOB-объектов, напрямую через REST API хранилища BLOB-объектов или из клиентской библиотеки службы хранилища Azure. Эти запросы начисляют плату за каждую транзакцию. Тип транзакции влияет на способ оплаты учетной записи. Например, транзакции чтения начисляются на категорию выставления счетов, отличную от категории операций записи. В следующей таблице показана категория выставления счетов для Put Block List запросов на основе типа учетной записи хранения.

Операция	Тип учетной записи хранения	Категория выставления счетов
Put Block List (Вставка списка блокировки)	Блочный BLOB-объект (ценовая категории "Премиум") Общего назначения версии 2 (цен. категория "Стандартный") Стандартная общего назначения версии 1	Операции записи

Дополнительные сведения о ценах для указанной категории выставления счетов см. в разделе Цены на Хранилище BLOB-объектов Azure.

См. также раздел

Общие сведения о блочных, добавочных и страничных BLOB-объектах
Авторизация запросов к службе хранилища Azure
Коды состояний и ошибок
Коды ошибок службы BLOB-объектов
Настройка времени ожидания для операций службы BLOB-объектов

Поделиться через