Put Block From URL

Статья
02/12/2024

Операция Put Block From URL создает новый блок, который будет зафиксирован как часть большого двоичного объекта, содержимое которого считывается из URL-адреса. Этот API доступен с версии 2018-03-28.

Запрос

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

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

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

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

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

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

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

Параметр Описание

blockid Обязательный. Допустимая строка в кодировке Base64, идентифицирующая блокировку. До кодирования длина строки не должна превышать 64 байта.

Для указанного большого двоичного объекта длина указанного значения параметра blockid должна быть одинаковой для каждого блока.

Примечание. Строка Base64 должна быть закодирована в ФОРМАТЕ URL.

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

Параметр	Описание
`blockid`	Обязательный. Допустимая строка в кодировке Base64, идентифицирующая блокировку. До кодирования длина строки не должна превышать 64 байта. Для указанного большого двоичного объекта длина указанного значения параметра `blockid` должна быть одинаковой для каждого блока. Примечание. Строка Base64 должна быть закодирована в ФОРМАТЕ URL.
`timeout`	Необязательный элемент. Параметр `timeout` указывается в секундах. Дополнительные сведения см. в разделе Настройка времени ожидания для операций службы BLOB-объектов.

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

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

Заголовок запроса	Описание
`Authorization`	Обязательный. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure.
`Date` или `x-ms-date`	Обязательный. Задает время запроса в формате UTC. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure.
`x-ms-version`	Требуется для всех авторизованных запросов. Задает версию операции, используемой для этого запроса. Дополнительные сведения см. в разделе Управление версиями для служб хранилища Azure. Для `Put Block From URL`должна быть версия 28.03.2018 или более поздняя.
`Content-Length`	Обязательный. Указывает число байтов, передаваемых в тексте запроса. Значение этого заголовка должно быть равно 0. Если длина не равна 0, операция завершается ошибкой с кодом состояния 400 (недопустимый запрос).
`x-ms-copy-source:name`	Обязательный. Указывает URL-адрес исходного большого двоичного объекта. Значением может быть URL-адрес длиной до 2 кибибайт (КиБ), указывающий большой двоичный объект. Значение должно быть закодировано в url-адресе, как оно будет отображаться в URI запроса. Исходный BLOB-объект должен быть общедоступным или авторизованным через подписанный URL-адрес. Если исходный BLOB-объект является общедоступным, для выполнения операции авторизация не требуется. Ниже приведены некоторые примеры URL-адресов исходного объекта: - `https://myaccount.blob.core.windows.net/mycontainer/myblob` - `https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>` - `https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>`
`x-ms-copy-source-authorization: <scheme> <signature>`	Необязательный элемент. Указывает схему авторизации и подпись для источника копирования. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure. Для Microsoft Entra поддерживается только схема носителя. Этот заголовок поддерживается в версиях 2020-10-02 и более поздних.
`x-ms-source-range`	Необязательный элемент. Передает только байты большого двоичного объекта в исходном URL-адресе в указанном диапазоне. Если этот заголовок не указан, все содержимое исходного BLOB-объекта отправляется в виде одного блока. Дополнительные сведения см. в разделе Указание заголовка диапазона для операций службы BLOB-объектов.
`x-ms-source-content-md5`	Необязательный элемент. Хэш MD5 содержимого блока из универсального кода ресурса (URI). Этот хэш используется для проверки целостности блока во время передачи данных из URI. Если указан этот заголовок, служба хранилища сравнивает хэш содержимого, полученного из источника копирования, с этим значением заголовка. Примечание. Этот хэш MD5 не хранится в большом двоичном объекте. Если два хэша не совпадают, операция завершается ошибкой с кодом 400 (недопустимый запрос).
`x-ms-source-content-crc64`	Необязательный элемент. Хэш CRC64 содержимого блока из универсального кода ресурса (URI). Этот хэш используется для проверки целостности блока во время передачи данных из URI. Если указан этот заголовок, служба хранилища сравнивает хэш содержимого, полученного из источника копирования, с этим значением заголовка. Примечание. Этот хэш CRC64 не хранится в большом двоичном объекте. Если два хэша не совпадают, операция завершается ошибкой с кодом 400 (недопустимый запрос). Если присутствуют оба `x-ms-source-content-md5` заголовка и `x-ms-source-content-crc64` , запрос завершается ошибкой с ошибкой 400 (недопустимый запрос). Этот заголовок поддерживается в версиях 2019-02-02 и более поздних версиях.
`x-ms-encryption-scope`	Необязательный элемент. Указывает область шифрования для шифрования исходного содержимого. Этот заголовок поддерживается в версиях 2019-02-02 и более поздних версиях.
`x-ms-lease-id:<ID>`	Требуется, если у большого двоичного объекта имеется активная аренда. Для выполнения этой операции в большом двоичном объекте с активной арендой укажите допустимый идентификатор аренды для этого заголовка.
`x-ms-client-request-id`	Необязательный элемент. Предоставляет созданное клиентом непрозрачное значение с ограничением в 1 кибибайт (КиБ), которое записывается в журналы при настройке ведения журнала. Мы настоятельно рекомендуем использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером. Дополнительные сведения см. в разделе Мониторинг Хранилище BLOB-объектов Azure.

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

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

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

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

Нет.

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

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

Ответ

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

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

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

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

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

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

Заголовок ответа	Описание
`Content-MD5`	Возвращается, чтобы клиент проверка для целостности содержимого сообщения. Значение этого заголовка вычисляется хранилищем BLOB-объектов. Оно не обязательно совпадает со значением, указанным в заголовках запроса. Для версий 2019-02-02 и более поздних этот заголовок возвращается только в том случае, если запрос содержит этот заголовок.
`x-ms-content-crc64`	Для версий 2019-02-02 и более поздних. Возвращается, чтобы клиент проверка для целостности содержимого сообщения. Значение этого заголовка вычисляется хранилищем BLOB-объектов. Оно не обязательно совпадает со значением, указанным в заголовках запроса. Возвращается, если `x-ms-source-content-md5` заголовок отсутствует в запросе.
`x-ms-request-id`	Уникально идентифицирует выполненный запрос, и его можно использовать для устранения неполадок с запросом. Дополнительные сведения см. в разделе Устранение неполадок с операциями API.
`x-ms-version`	Версия хранилища BLOB-объектов, которая использовалась для выполнения запроса.
`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-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: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Авторизация

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

Важно!

Корпорация Майкрософт рекомендует использовать 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 From URL операции, а также встроенная роль Azure RBAC с наименьшими привилегиями, которая включает это действие:

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

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

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

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

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

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

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

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

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

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

SAS для службы

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

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

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

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

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

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

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

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

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

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

Put Block From URL передает блокировку с целью будущего включения в блочный большой двоичный объект. Блочный BLOB-объект может содержать не более 50 000 блоков. Каждый блок может иметь разный размер. Максимальный размер блока, передаваемого с Put Block From URL помощью , составляет 100 мебибайт (МиБ). Сведения о том, как отправить большие блоки (до 4000 МиБ), см. в разделе Put Block.

В версии 2020-10-02 и более поздних Microsoft Entra авторизация поддерживается для источника операции копирования.

Большой двоичный объект может содержать не более 100 000 незафиксированных блоков в любое время. При превышении этого максимального значения служба возвращает код состояния 409 (RequestEntityTooLargeBlockCountExceedsLimit).

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

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

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

При вызове Put Block From URL для большого двоичного объекта, который еще не существует, создается новый блочный BLOB-объект с длиной содержимого 0. Этот большой двоичный объект перечисляется операцией List Blobs, если указан параметр include=uncommittedblobs. Переданные блокировки не фиксируются до вызова операции Put Block List для нового большого двоичного объекта. Созданный таким образом BLOB-объект хранится на сервере в течение недели. Если вы не добавили дополнительные блоки или зафиксированные блоки в большой двоичный объект в течение этого периода времени, большой двоичный объект собирается мусор.

Блок, успешно переданный с Put Block From URL помощью операции, не становится частью большого двоичного объекта, пока не будет зафиксирован с Put Block Listпомощью . Перед Put Block List вызовом для фиксации нового или обновленного большого двоичного объекта все вызовы get BLOB-объекта возвращают содержимое большого двоичного объекта без включения незафиксированного блока.

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

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

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

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

Вызов Put Block From URL не обновляет время последнего изменения существующего BLOB-объекта.

При вызове Put Block From URL для страничного большого двоичного объекта возвращается ошибка.

Вызов Put Block From URL большого двоичного объекта "архива" возвращает ошибку, а его вызов для большого hot двоичного объекта или cool не изменяет уровень большого двоичного объекта.

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

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

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

¹С целевой учетной записи взимается плата за одну транзакцию для запуска записи.
²Исходная учетная запись выполняет одну транзакцию для каждого запроса на чтение к исходному объекту.

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

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

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