Поместить список блокировок

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

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

запрос

Можно создать запрос 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

Эмулятор памяти поддерживает размеры blob до 2 гибибайт (GiB).

Дополнительные сведения см. в статье Использование эмулятора 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 (недопустимый запрос).

Этот заголовок ассоциируется с содержимым запроса, а не с содержанием самого blob-а.
x-ms-content-crc64 Необязательно. Хэш CRC64 содержимого запроса. Этот хэш используется для проверки целостности содержимого запроса во время транспорта. Если два хэша не соответствуют, операция завершается ошибкой с кодом 400 (недопустимый запрос).

Этот заголовок ассоциируется с содержимым запроса, а не с содержанием самого blob-а.

Если присутствуют оба заголовка Content-MD5 и x-ms-content-crc64, запрос не выполняется при 400 (плохой запрос).

Этот заголовок поддерживается в версии 2019-02-02 и более поздних версиях.
x-ms-blob-cache-control Необязательно. Устанавливает контроль кэша blob-а. Если это свойство указано, оно сохраняется вместе с blob и возвращается с запросом на чтение.

Если свойство не указано в запросе, оно очищается для blob, если запрос выполнен успешно.
x-ms-blob-content-type Необязательно. Это задаёт тип контента блоба. Если это указано, это свойство сохраняется вместе с blob и возвращается с запросом на чтение.

Если тип содержимого не указан, он устанавливается на тип по умолчанию, то есть application/octet-stream.
x-ms-blob-content-encoding Необязательно. Устанавливает кодировку содержания блоба. Если это указано, это свойство сохраняется вместе с blob и возвращается с запросом на чтение.

Если свойство не указано в запросе, оно очищается для blob, если запрос выполнен успешно.
x-ms-blob-content-language Необязательно. Задаёт язык содержания блоба. Если это указано, это свойство сохраняется вместе с blob и возвращается с запросом на чтение.

Если свойство не указано в запросе, оно очищается для blob, если запрос выполнен успешно.
x-ms-blob-content-md5 Необязательно. Хэш MD5 содержимого большого двоичного объекта. Этот хэш не валидируется, потому что хэши отдельных блоков были проверены при загрузке.

Операция Get Blob возвращает значение этого заголовка в ответном заголовке Content-MD5.

Если это свойство не указано в запросе, оно очищается для blob, если запрос успешен.
x-ms-meta-name:value Необязательно. Пользовательские пары имя-значение, связанные с blob.

С версии 2009-09-19 имена метаданных должны соответствовать правилам именования идентификаторов C#.
x-ms-encryption-scope Необязательно. Указывает область шифрования для шифрования blob. Это значение должно совпадать с областью шифрования, используемой для шифрования всех блоков, которые фиксируются. Этот заголовок поддерживается в версии 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 кибибайт (KiB), которое фиксируется в аналитических журналах при настройке логов аналитики хранилища. Настоятельно рекомендуется использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером.
x-ms-blob-content-disposition Необязательно. Устанавливает Content-Disposition заголовок Blob's. Доступно для версии 2013-08-15 и более поздних версий.

Поле Content-Disposition заголовка передаёт дополнительную информацию о том, как обрабатывать ответную полезную нагрузку, и может использоваться для прикрепления дополнительных метаданных. Например, если он установлен на attachment, этот заголовок указывает, что user-agent не должен отображать ответ, а должен показывать диалог «Сохранить как».

Ответ операций Get Blob и Get Blob Properties включает заголовок content-disposition.
x-ms-access-tier Необязательно. Версия 2018-11-09 и позже. Указывает уровень, который нужно установить на блобе. Для блочных блобов этот заголовок поддерживается на блоб-хранилище или в общих аккаунтах v2 только с версией 2018-11-09 и более поздней. Допустимые значения для уровней блочных блопов — Hot, Cool, Cold, Smart и Archive.
Примечание. УровеньCold поддерживается для версии 2021-12-02 и более поздних версий. Smart Tier поддерживается для версий 2026-02-06 и выше, сейчас находится в публичном предпросмотре.
Для подробной информации о уровне блочных блобов см. Уровни хранения блобов в разделе «Blob storage tiers».
x-ms-immutability-policy-until-date Версия 2020-06-12 и выше. Указывает дату удержания , которую нужно установить на блобе. Это дата, до которой большой двоичный объект может быть защищен от изменения или удаления. Соответствует RFC1123 формату.
x-ms-immutability-policy-mode Версия 2020-06-12 и выше. Задаёт режим политики неизменяемости, который нужно установить на блобе. Допустимые значения — unlocked и locked. Это unlocked значение указывает на то, что пользователи могут изменить политику, увеличив или уменьшив дату удержания до срока. Значение locked указывает на то, что эти действия запрещены.
x-ms-legal-hold Версия 2020-06-12 и выше. Указывает юридическую удержательность на blob. Возможные значения: true и false.
x-ms-expiry-option Необязательно. Версия 2023-08-03 и более поздняя. Указывает опцию срока действия для запроса, см. ExpiryOption. Этот заголовок действует для аккаунтов с включённым иерархическим пространством имён.
x-ms-expiry-time Необязательно. Версия 2023-08-03 и более поздняя. Указывает время, когда блоб установлен на истечение. Формат срока годности варьируется в зависимости от x-ms-expiry-option. Для получения дополнительной информации смотрите ExpiryOption. Этот заголовок действует для аккаунтов с включённым иерархическим пространством имён.

Уже expiryTime присутствующее на блобе не очищается, если запрос не содержит нового значения expiryTime

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

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

По состоянию на версию 2019-02-02 вы можете указать следующие заголовки в запросе на шифрование blob с ключом, предоставленным клиентом. Шифрование с помощью предоставленного клиентом ключа (и соответствующего набора заголовков) является необязательным.

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

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

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

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

  • Укажите идентификатор блока внутри Committed элемента, чтобы показать, что Blob Storage должен искать только указанный блок в зафиксированном списке блоков. Если блок не находится в коммитированном списке блоков, он не записывается как часть blob, и Blob Storage возвращает статус 400 (Плохой запрос).

  • Укажите идентификатор блока внутри Uncommitted элемента, чтобы показать, что Blob Storage должен искать только незафиксированный список блоков по именованому блоку. Если блок не находится в списке незакреплённых блоков, он не записывается как часть blob, и Blob Storage возвращает статус 400 (Плохой запрос).

  • Укажите блок ID внутри элемента Latest , чтобы показать, что Blob Storage должен сначала искать в незакреплённом списке блокировок. Если блокировка найдена в списке незакреплённых, эта версия блокировки является последней и должна быть записана в 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, предположим, что вы загрузили три блока, которые теперь хотите зафиксировать. Следующий пример фиксирует новый 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 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. Новый блоб имеет следующие изменения:

  • Новый блок с ID ANAAAA==. Этот блок должен быть сначала загружен с помощью вызова Put Block, и он появляется в списке незакреплённых блокировок до тех пор, пока не произойдёт вызов .Put Block List

  • Обновлённая версия блока с ID AZAAAA==. Этот блок должен быть сначала загружен с помощью вызова Put Block, и он появляется в списке незакреплённых блокировок до тех пор, пока не произойдёт вызов .Put Block List

  • Удаление блокировки с ID AAAAAA==. Поскольку этот блок не включен в следующий вызов Put Block List, блок фактически удаляется из blob.

Следующий пример показывает вызов, Put Block List который обновляет 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>

Ответ

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

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

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

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

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

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

Ответ Описания
ETag Тег сущности содержит значение, которое клиент может использовать для выполнения условных GET/PUT операций с помощью If-Match заголовка запроса. Если версия запроса — 2011-08-18 или более поздняя, значение ETag заключено в кавычки.
Last-Modified Дата и время последнего изменения большого двоичного объекта. Формат даты следует RFC 1123. Дополнительные сведения см. в разделе Представление значений даты и времени в заголовках.

Любая операция, которая изменяет большой двоичный объект, включая обновление метаданных или свойств большого двоичного объекта, изменяет время последнего изменения большого двоичного объекта.
Content-MD5 Возвращается, чтобы клиент мог проверить целостность содержимого сообщения. Этот заголовок относится к содержимому запроса (в данном случае — к списку блоков, а не к содержимому самого blob-а). Для версии 2019-02-02 и более поздних сроков этот заголовок возвращается только тогда, когда запрос содержит этот заголовок.
x-ms-content-crc64 Для версий 2019-02-02 и более поздних этот заголовок возвращается, чтобы клиент мог проверить целостность содержимого сообщения. Этот заголовок относится к содержимому запроса (в данном случае — к списку блоков, а не к содержимому самого blob-а).

Этот заголовок возвращается, когда Content-md5 заголовок отсутствует в запросе.
x-ms-request-id Уникально идентифицирует выполненный запрос, и его можно использовать для устранения неполадок запроса. Дополнительные сведения см. в статье Устранение неполадок с операциями API.
x-ms-version Версия Blob Storage, которая используется для выполнения запроса. Этот заголовок возвращается для запросов, выполненных в отношении версии 2009-09-19 и более поздних.
Date Значение даты/времени UTC, которое генерируется сервисом и указывает момент инициации ответа.
x-ms-request-server-encrypted: true/false Версия 2015-12-11 и выше. Значение этого заголовка задаётся так, true если содержимое запроса успешно зашифровано с использованием указанного алгоритма. В противном случае значение устанавливается в false.
x-ms-encryption-key-sha256 Версия 2019-02-02 и более поздних версий. Этот заголовок возвращается, если запрос использовал ключ, предоставленный клиентом, для шифрования, чтобы клиент мог убедиться, что содержимое запроса успешно зашифровано, используя предоставленный ключ.
x-ms-encryption-scope Версия 2019-02-02 и более поздних версий. Этот заголовок возвращается, если запрос использовал область шифрования, поэтому клиент может убедиться, что содержимое запроса успешно зашифровано, используя область шифрования.
x-ms-version-id: <DateTime> Версия 2019-12-12 и выше. Возвращает непрозрачное значение DateTime, которое однозначно идентифицирует большой двоичный объект. Значение этого заголовка указывает версию blob, и его можно использовать в последующих запросах для доступа к blob.
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>

Authorization

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

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

Это важно

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

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

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

Разрешения

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

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

Замечания

Операция Put Block List определяет порядок комбинирования блоков для создания blob-а.

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

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

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

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

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

Версия службы Максимальный размер блока (через Put Block) Максимальный размер капли (через Put Block List) Максимальный размер капли с помощью одной операции записи (через Put Blob)
Версия 2019-12-12 и более поздние 4 000 мебибайт (MiB) Примерно 190,7 тебибайт (TiB) (4 000 МиБ × 50 000 блоков) 5 000 MiB
Версии 2016-05-31 по 2019-07-07 100 МиБ Примерно 4,75 TiB (100 MiB × 50 000 блоков) 256 МиБ
Версии, ранее 31.05.2016 4 МиБ Примерно 195 ГиБ (4 МиБ × 50 000 блоков) 64 МиБ

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

Если Put Block List операция не удаётся из-за отсутствующего блока, нужно загрузить этот блок.

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

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

Если у blob есть активный договор аренды, клиент должен указать действительный идентификатор аренды в запросе для фиксации блок-листа. Если клиент либо не указывает идентификатор аренды, либо указывает недействительный идентификатор аренды, Blob Storage возвращает статус 412 (предварительное условие не выполнено). Если клиент указывает идентификатор аренды, но у blob нет активного договора аренды, Blob Storage также возвращает статус 412 (предварительное условие не выполнено). Если клиент указывает идентификатор аренды на блобе, который ещё не существует, Blob Storage возвращает статус 412 (Предварительное условие не выполнено) для запросов, сделанных по версии 2013-08-15 или новее. Для ранних версий Blob Storage возвращает статус 201 (Создан).

Если у blob активный договор аренды, и вы звоните Put Block List для обновления blob, договор аренды сохраняется на обновлённом блобе.

Put Block List Применяется только к блокировкам. Вызов Put Block List блоба страницы приводит к коду статуса 400 (Плохой запрос).

Перезапись blob archive не удаётся. В противном случае blob наследует уровень от старого blob, если x-ms-access-tier заголовок не предоставлен.

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

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

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

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

См. также

Понимайте блоки, добавляйте блобы и страницы
Авторизация запросов в службу хранилища Azure
Коды состояний и ошибок
Коды ошибок сервиса Blob
Установка тайм-аутов для операций сервиса Blob

  • Last updated on