Поместить страницу с URL

Эта Put Page From URL операция записывает диапазон страниц в страничный BLOB-объект, где содержимое считывается из URL-адреса. Этот API доступен по состоянию на версию 2018-11-09.

Просьба

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

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

URI эмулированной службы хранилища

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

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

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

Параметры URI

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

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

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

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

Заголовок запроса	Описание
`Authorization`	Обязательное. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
`Date` или `x-ms-date`	Обязательное. Указывает универсальное время (UTC) для запроса. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
`x-ms-version`	Требуется для всех авторизованных запросов. Указывает версию операции, используемой для этого запроса. Дополнительные сведения см. в разделе Управление версиями служб хранилища Azure.
`Range`	Либо `Range`, либо `x-ms-range` требуется. Указывает диапазон байтов, которые должны быть записаны в виде страницы. Необходимо указать начало и конец диапазона. Этот заголовок определяется спецификацией протокола HTTP/1.1 . Для операции обновления страниц диапазон страниц может составлять до 4 МиБ. Поскольку страницы должны быть выровнены по границам размером 512 байт, начальное смещение должно быть модулем 512, а конечное смещение должно быть модулем 512 – 1. Примерами допустимых диапазонов байтов являются 0-511, 512-1023 и т. д. Служба BLOB-объектов принимает только один диапазон байтов для `Range` заголовка, и диапазон байтов должен быть указан в следующем формате: `bytes=startByte-endByte`. Если указаны оба `Range` и `x-ms-range`, служба использует значение `x-ms-range`. Дополнительные сведения см. в статье Указание заголовка диапазона для операций службы BLOB-объектов.
`x-ms-range`	Либо `Range`, либо `x-ms-range` требуется. Указывает диапазон байтов, которые должны быть записаны в виде страницы. Необходимо указать начало и конец диапазона. Этот заголовок определяется спецификацией протокола HTTP/1.1 . Диапазон страниц может составлять до 4 МиБ. Поскольку страницы должны быть выровнены по границам размером 512 байт, начальное смещение должно быть модулем 512, а конечное смещение должно быть модулем 512 – 1. Примерами допустимых диапазонов байтов являются 0-511, 512-1023 и т. д. Служба BLOB-объектов принимает только один диапазон байтов для `x-ms-range` заголовка, и диапазон байтов должен быть указан в следующем формате: `bytes=startByte-endByte`. Если указаны оба `Range` и `x-ms-range`, служба использует значение `x-ms-range`. Дополнительные сведения см. в статье Указание заголовка диапазона для операций службы BLOB-объектов.
`Content-Length`	Обязательное. Указывает количество байтов, передаваемых в тексте запроса. Значение этого заголовка должно быть равно нулю. Если длина не равна нулю, операция завершается ошибкой с кодом состояния 400 (недопустимый запрос).
`x-ms-copy-source:name`	Обязательное. Указывает URL-адрес исходного большого двоичного объекта. Значением может быть URL-адрес длиной до 2 КБ, указывающий большой двоичный объект. Значение должно быть закодировано URL-адресом, так как оно будет отображаться в URI запроса. Исходный BLOB-объект должен быть либо общедоступным, либо авторизованным с помощью подписанного URL-адреса. Если исходный большой двоичный объект является общедоступным, для выполнения операции не требуется авторизация. Ниже приведены некоторые примеры 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-адрес в указанном диапазоне. Необходимо указать начало и конец диапазона. Этот заголовок определяется спецификацией протокола HTTP/1.1 . Диапазон страниц может составлять до 4 МиБ. Служба BLOB-объектов принимает только один диапазон байтов для `x-ms-source-range` заголовка, и диапазон байтов должен быть указан в следующем формате: `bytes=startByte-endByte`. Дополнительные сведения см. в статье Указание заголовка диапазона для операций службы 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` заголовка and `x-ms-source-content-crc64` , запрос завершается ошибкой со значением 400 (Bad Request). Этот заголовок поддерживается в версии 2019-02-02 и более поздних версиях.
`x-ms-lease-id:<ID>`	Требуется, если большой двоичный объект имеет действующую аренду. Чтобы выполнить эту операцию в большом двоичном объекте с активной арендой, укажите допустимый идентификатор аренды для этого заголовка.
`x-ms-if-sequence-number-le: <num>`	Необязательно. Если порядковый номер большого двоичного объекта меньше или равен указанному значению, запрос продолжается. В противном случае произойдет сбой с ошибкой SequenceNumberConditionNotMet (код состояния HTTP 412 — Precondition Failed).
`x-ms-if-sequence-number-lt: <num>`	Необязательно. Если порядковый номер большого двоичного объекта меньше указанного значения, запрос продолжается. В противном случае произойдет сбой с ошибкой SequenceNumberConditionNotMet (код состояния HTTP 412 — Precondition Failed).
`x-ms-if-sequence-number-eq: <num>`	Необязательно. Если порядковый номер большого двоичного объекта равен указанному значению, запрос продолжается. В противном случае произойдет сбой с ошибкой SequenceNumberConditionNotMet (код состояния HTTP 412 — Precondition Failed).
`If-Modified-Since`	Необязательно. Некоторое значение `DateTime`. Укажите этот условный заголовок, чтобы страница записывалась только в том случае, если большой двоичный объект был изменен с указанной даты и времени. Если большой двоичный объект не был изменен, служба BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`If-Unmodified-Since`	Необязательно. Некоторое значение `DateTime`. Укажите этот условный заголовок, чтобы страница записывалась только в том случае, если большой двоичный объект не изменялся с указанной даты и времени. Если большой двоичный объект был изменен, служба BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`If-Match`	Необязательно. Значение ETag. Укажите значение ETag для этого условного заголовка, чтобы страница записывалась только в том случае, если значение ETag большого двоичного объекта совпадает с указанным значением. Если значения не совпадают, служба BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`If-None-Match`	Необязательно. Значение ETag. Укажите значение ETag для этого условного заголовка, чтобы страница записывалась только в том случае, если значение ETag большого двоичного объекта не соответствует указанному значению. Если значения идентичны, служба BLOB-объектов возвращает код состояния 412 (сбой предварительных условий).
`x-ms-encryption-scope`	Необязательно. Указывает область шифрования, используемую для шифрования исходного содержимого. Этот заголовок поддерживается в версии 2019-02-02 и более поздних версиях.
`x-ms-client-request-id`	Необязательно. Предоставляет созданное клиентом непрозрачное значение с ограничением символов 1-kibibyte (KiB), записанным в журналах при настройке ведения журнала. Настоятельно рекомендуется использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером. Дополнительные сведения см. в статье Monitorхранилища BLOB-объектов Azure.
`x-ms-file-request-intent`	Обязательно, если `x-ms-copy-source` заголовок является URL-адресом файла Azure и `x-ms-copy-source-authorization` в заголовке указан маркер OAuth. Допустимое значение равно `backup`. Этот заголовок указывает, что `Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action` или `Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action` следует предоставить, если они включены в политику RBAC, назначенную удостоверению, авторизованному с помощью заголовка `x-ms-copy-source-authorization`. Доступно для версии 2025-07-05 и выше.

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

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

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

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

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

По состоянию на версию 2026-02-06 в запросе на копирование blob, зашифрованного ключом, предоставленным клиентом, можно указать следующие заголовки. Эти заголовки нужны только тогда, когда исходный blob в Azure Storage зашифрован с помощью ключа, предоставленного клиентом.

До этой функции клиенты могли вращать ключи, предоставленные клиентом, только на стороне клиента, скачивая blob со старым ключом и перезагружая его с новым ключом. С этими новыми заголовками клиенты теперь могут полностью зашифровывать blob на стороне сервера. Например, клиенты могут указывать key1 в исходных заголовках ключей, предоставленных клиентом, и key2 в заголовках ключей, предоставленных клиентом. Кроме того, клиенты могут расшифровать blob, применяя только ключевые заголовки, предоставленные источником.

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

Основное содержание запроса

Тело запроса содержит содержимое страницы.

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

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:   
x-ms-date: Fri, 16 Sep 2011 22:15:50 GMT  
x-ms-version: 2018-11-09  
x-ms-range: bytes=0-65535  
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=  
Content-Length: 0

Ответ

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

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

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

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

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

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

Синтаксис	Описание
`ETag`	ETag для большого двоичного объекта. Если версия запроса — 2011-08-18 и более поздняя, значение ETag заключается в кавычки. ETag можно использовать для выполнения условной `Put Page From URL` операции, указав его значение в заголовке `If-Match` запроса or `If-None-Match` .
`Last-Modified`	Дата и время последнего изменения объекта BLOB. Формат даты следует RFC 1123. Дополнительные сведения см. в разделе Представление значений даты и времени в заголовках. Любая операция записи большого двоичного объекта, включая обновление метаданных или свойств большого двоичного объекта, изменяет время последнего изменения большого двоичного объекта.
`Content-MD5`	Возвращается, чтобы клиент смог проверить целостность содержимого сообщения. Значение этого заголовка вычисляется службой BLOB-объектов. Это не обязательно совпадает со значением, указанным в заголовках запроса. Для версии 2019-02-02 или более поздней этот заголовок возвращается только в том случае, если запрос содержит этот заголовок.
`x-ms-content-crc64`	Для версии 2019-02-02 или более поздней. Возвращается, чтобы клиент смог проверить целостность содержимого сообщения. Значение этого заголовка вычисляется службой BLOB-объектов. Это не обязательно совпадает со значением, указанным в заголовках запроса. Этот заголовок возвращается, если `x-ms-source-content-md5` он отсутствует в запросе.
`x-ms-blob-sequence-number`	Текущий номер последовательности для большого двоичного объекта страницы.
`x-ms-request-id`	Уникально идентифицирует выполненный запрос и может использоваться для устранения неполадок запроса. Дополнительные сведения см. в статье Устранение неполадок с операциями API.
`x-ms-version`	Указывает версию службы BLOB-объектов, которая использовалась для выполнения запроса. Этот заголовок возвращается для запросов, выполненных в отношении версии 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-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 22:33:35 GMT  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: Sun, 25 Sep 2011 12:13:31 GMT  
x-ms-version: 2011-08-18  
x-ms-blob-sequence-number: 0  
Content-Length: 0  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Авторизация

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

Это важно

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

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

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

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

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

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

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

Делегирование пользователей с помощью SAS

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

Вызов операции Put Page From URL с помощью маркера SAS, делегированного контейнеру или ресурсу БОЛЬШОго двоичного объекта, требует разрешения записи (w) в рамках маркера SAS делегирования пользователей.

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

Сервис SAS

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

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

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

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

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

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

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

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

Замечания

Эта Put Page From URL операция записывает диапазон страниц в страничный BLOB-объект. Эту операцию можно вызвать только для существующего страничного BLOB-объекта. Его нельзя вызвать для создания нового страничного BLOB-объекта, а также для блочного BLOB-объекта. При вызове Put Page From URL с именем большого двоичного объекта, который в настоящее время не существует, возвращается ошибка BlobNotFound (код состояния HTTP 404 — Not Found).

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

Чтобы создать новый страничный BLOB-объект, вызовите Put Blob и укажите тип BLOB-объекта, который будет создан в качестве страничного BLOB-объекта. Размер страничного BLOB-объекта может достигать 8 ТиБ.

Если у большого двоичного объекта есть активная аренда, клиент должен указать действительный идентификатор аренды в запросе на создание страницы.

Операции по обновлению страниц

При вызове Put Page From URL выполняется запись на месте в указанный страничный BLOB-объект. Любой контент на указанной странице перезаписывается при обновлении.

Это важно

Если время ожидания сервера истекает или ваше соединение прерывается во время , Put Page From URLстраница может быть обновлена или не обновиться. Поэтому следует продолжать повторять попытку обновления до тех пор, пока не будет получен ответ об успешном выполнении.

Каждый диапазон страниц, отправляемых Put Page From URL для операции обновления, может иметь размер до 4 МиБ. Начальный и конечный диапазоны страницы должны быть выровнены по границам размером 512 байт. Если вы попытаетесь отправить диапазон страниц, размер которого превышает 4 МиБ, служба вернет код состояния 413 (Request Entity Too Large).

Управление проблемами параллелизма

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

Вы можете проверить значение заголовка ответа Last-Modified для каждого успешного вызова Put Page From URL. Порядок ответов, возвращаемых службой BLOB-объектов, не обязательно соответствует порядку, в котором они были выполнены службой. Но значение of Last-Modified всегда указывает на порядок, в котором сервис обрабатывал запросы.
Вы можете выполнять обновления условно на основе ETag большого двоичного объекта или времени последнего изменения с помощью оптимистичного параллелизма. Этот подход хорошо работает, если количество одновременных операций записи относительно невелико. Используйте заголовки условных запросов If-Match, If-None-Match, If-Modified-Since, и If-Unmodified-Since для этой цели.
Вы можете вызвать службу аренды BLOB-объекта , чтобы заблокировать большой двоичный объект от других операций записи на одну минуту или дольше, если аренда продлевается.
Вы можете использовать порядковый номер большого двоичного объекта, чтобы гарантировать, что повторная попытка запроса, на который не было ответа, не приведет к одновременным обновлениям. Этот подход может быть лучшим для клиентов, которым требуется высокая пропускная способность для записи страниц. Он подробно описан в следующем разделе.

Использование порядкового номера страничного BLOB-объекта для повторных запросов

Если время ожидания вызова Put Page From URL истекает или ответ не возвращается, невозможно узнать наверняка, был ли запрос выполнен успешно. Таким образом, необходимо повторить запрос, но из-за распределенного характера служб хранилища Azure исходный запрос может быть обработан после успешного выполнения повторного запроса. Отложенный исходный запрос может перезаписать другие обновления и привести к неожиданному результату. Следующая последовательность иллюстрирует, как это может произойти:

Запрос Put Page From URL на запись значения "X" на страницу 0 истекает или не возвращает ответ.
Повторный запрос на запись значения "X" на страницу 0 завершается успешно.
Запрос на запись значения "Y" на страницу 0 выполнен успешно.
Исходный запрос выполнен успешно, значение "X" записывается на страницу 0.
Чтение страницы 0 возвращает значение "X", когда клиент в этот момент ожидал значение "Y".

Такого рода конфликт может возникнуть, если исходный запрос не возвращает код состояния в диапазоне от 100 до 499 или 503 (сервер занят). Если возвращается один из этих кодов состояния, вы можете быть уверены в том, был ли запрос успешным или неудачным. Но если служба возвращает код состояния за пределами этого диапазона, невозможно узнать состояние исходного запроса.

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

Клиент создает страничный BLOB-объект с помощью функции Put Blob и задает для него порядковый номер равным 0.
Запрос Put Page From URL на запись значения "X" на страницу 0 с заголовком, if-sequence-number-lt для которого установлено время 1 ожидания, или не возвращает ответ.
Клиент вызывает команду Set Blob Properties, чтобы обновить порядковый номер до 1.
Повторный запрос на запись значения "X" на страницу 0 с установленным if-sequence-number-lt значением " 2 успешно".
Запрос на запись значения "Y" на страницу 0 с установленным if-sequence-number-lt значением " 2 Succeeded".
Исходный запрос окончательно обрабатывается, но завершается неудачей, так как в нем указано условие, что порядковый номер должен быть меньше 1 (то есть заголовок if-sequence-num-lt устанавливается в значение 1). Ошибка — SequenceNumberConditionNotMet (код состояния HTTP 412 — Precondition Failed).
При чтении страницы 0 возвращается ожидаемое значение "Y".

См. также

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

Last updated on 2026-01-22