Put Page From URL

Article
05/15/2024

L’opération Put Page From URL écrit une plage de pages dans un objet blob de pages où le contenu est lu à partir d’une URL. Cette API est disponible à partir de la version 2018-11-09.

Requête

Vous pouvez construire la Put Page From URL requête comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez moncompte par le nom de votre compte de stockage :

URI de requête de méthode PUT	Version HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page`	HTTP/1.1

URI du service de stockage émulé

Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port du service Blob en tant que 127.0.0.1:10000, suivis du nom du compte de stockage émulé :

URI de requête de méthode PUT	Version HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page`	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre	Description
`timeout`	facultatif. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de service Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête	Description
`Authorization`	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
`Date` ou `x-ms-date`	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
`x-ms-version`	Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
`Range`	`Range` ou `x-ms-range` est requis. Spécifie la plage d'octets à écrire en tant que page. Le début et la fin de la plage doivent être spécifiés. Cet en-tête est défini par la spécification du protocole HTTP/1.1. Pour une opération de mise à jour de page, la plage de pages peut atteindre 4 Mio. Étant donné que les pages doivent être alignées avec des limites de 512 octets, le décalage de début doit être un module de 512 et le décalage de fin doit être un module de 512 à 1. Exemples de plages d’octets valides : 0-511, 512-1023, etc. Le service BLOB accepte une seule plage d'octets pour l'en-tête `Range`, et la plage d'octets doit être spécifiée dans le format suivant : `bytes=startByte-endByte`. Si `Range` et `x-ms-range` sont spécifiés, le service utilise la valeur de `x-ms-range`. Pour plus d’informations, consultez Spécifier l’en-tête de plage pour les opérations de service Blob.
`x-ms-range`	`Range` ou `x-ms-range` est requis. Spécifie la plage d'octets à écrire en tant que page. Le début et la fin de la plage doivent être spécifiés. Cet en-tête est défini par la spécification du protocole HTTP/1.1. La plage de pages peut atteindre 4 Mio. Étant donné que les pages doivent être alignées avec des limites de 512 octets, le décalage de début doit être un module de 512 et le décalage de fin doit être un module de 512 à 1. Exemples de plages d’octets valides : 0-511, 512-1023, etc. Le service BLOB accepte une seule plage d'octets pour l'en-tête `x-ms-range`, et la plage d'octets doit être spécifiée dans le format suivant : `bytes=startByte-endByte`. Si `Range` et `x-ms-range` sont spécifiés, le service utilise la valeur de `x-ms-range`. Pour plus d’informations, consultez Spécifier l’en-tête de plage pour les opérations de service Blob.
`Content-Length`	Obligatoire. Indique le nombre d'octets transmis dans le corps de demande. La valeur de cet en-tête doit être définie sur zéro. Lorsque la longueur n’est pas égale à zéro, l’opération échoue avec le code status 400 (requête incorrecte).
`x-ms-copy-source:name`	Obligatoire. Spécifie l’URL de l’objet blob source. La valeur peut être une URL d’une longueur maximale de 2 Kio qui spécifie un objet blob. La valeur doit être encodée sous forme d'URL, comme dans une URI de demande. L’objet blob source doit être public ou doit être autorisé via une signature d’accès partagé. Si l’objet blob source est public, aucune autorisation n’est requise pour effectuer l’opération. Voici quelques exemples d’URL d’objet source : - `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>`	facultatif. Spécifie le schéma d’autorisation et la signature pour la source de copie. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure. Seul un porteur de schéma est pris en charge pour Microsoft Entra. Cet en-tête est pris en charge dans la version 2020-10-02 et ultérieure.
`x-ms-source-range`	Charge les octets de l’objet blob dans l’URL source dans la plage spécifiée. Le début et la fin de la plage doivent être spécifiés. Cet en-tête est défini par la spécification du protocole HTTP/1.1. La plage de pages peut atteindre 4 Mio. Le service BLOB accepte une seule plage d'octets pour l'en-tête `x-ms-source-range`, et la plage d'octets doit être spécifiée dans le format suivant : `bytes=startByte-endByte`. Pour plus d’informations, consultez Spécifier l’en-tête de plage pour les opérations de service Blob .
`x-ms-source-content-md5`	facultatif. Hachage MD5 du contenu de la page à partir de l’URI. Ce hachage est utilisé pour vérifier l’intégrité de la page pendant le transport des données à partir de l’URI. Lorsque cet en-tête est spécifié, le service de stockage compare le hachage du contenu qui est arrivé de la source de copie à cette valeur d’en-tête. Remarque : ce hachage MD5 n’est pas stocké avec l’objet blob. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte).
`x-ms-source-content-crc64`	facultatif. Hachage CRC64 du contenu de la page à partir de l’URI. Ce hachage est utilisé pour vérifier l’intégrité de la page pendant le transport des données à partir de l’URI. Lorsque cet en-tête est spécifié, le service de stockage compare le hachage du contenu qui est arrivé de la source de copie à cette valeur d’en-tête. Remarque : Ce hachage CRC64 n’est pas stocké avec l’objet blob. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte). Si les en-têtes `x-ms-source-content-md5` et `x-ms-source-content-crc64` sont présents, la requête échoue avec un 400 (requête incorrecte). Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
`x-ms-lease-id:<ID>`	Obligatoire si l'objet blob a un bail actif. Pour effectuer cette opération sur un objet blob avec un bail actif, spécifiez l'ID de bail valide pour cet en-tête.
`x-ms-if-sequence-number-le: <num>`	facultatif. Si le numéro de séquence de l’objet blob est inférieur ou égal à la valeur spécifiée, la demande se poursuit. Sinon, elle échoue avec l’erreur SequenceNumberConditionNotMet (code http status 412 – Échec de la condition préalable).
`x-ms-if-sequence-number-lt: <num>`	facultatif. Si le numéro de séquence de l’objet blob est inférieur à la valeur spécifiée, la demande continue. Sinon, elle échoue avec l’erreur SequenceNumberConditionNotMet (code HTTP status 412 – Échec de la condition préalable).
`x-ms-if-sequence-number-eq: <num>`	facultatif. Si le numéro de séquence de l’objet blob est égal à la valeur spécifiée, la demande se poursuit. Sinon, elle échoue avec l’erreur SequenceNumberConditionNotMet (code HTTP status 412 – Échec de la condition préalable).
`If-Modified-Since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour écrire la page uniquement si l'objet blob été modifié depuis la date/l'heure indiquées. Si l’objet blob n’a pas été modifié, le service Blob retourne status code 412 (Échec de la condition préalable).
`If-Unmodified-Since`	facultatif. Valeur `DateTime`. Spécifiez cet en-tête conditionnel pour écrire la page uniquement si l’objet blob n’a pas été modifié depuis la date/heure spécifiée. Si l'objet blob a été modifié, le service BLOB retourne le code d'état 412 (Échec de la précondition).
`If-Match`	facultatif. Spécifiez une valeur ETag. Spécifiez une valeur d'ETag pour cet en-tête conditionnel pour écrire la page uniquement si la valeur d'ETag de l'objet blob correspond à la valeur spécifiée. Si les valeurs ne correspondent pas, le service Blob retourne status code 412 (Échec de la condition préalable).
`If-None-Match`	facultatif. Spécifiez une valeur ETag. Spécifiez une valeur ETag pour cet en-tête conditionnel afin d’écrire la page uniquement si la valeur ETag de l’objet blob ne correspond pas à la valeur spécifiée. Si les valeurs sont identiques, le service BLOB renvoie le code d'état 412 (Échec de la précondition).
`x-ms-encryption-scope`	facultatif. Indique l’étendue de chiffrement à utiliser pour chiffrer le contenu source. Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
`x-ms-client-request-id`	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes reçues par le serveur. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

Cette opération prend également en charge l'utilisation d'en-têtes conditionnels pour exécuter l'opération uniquement si une condition est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de service Blob.

En-têtes de requête (clés de chiffrement fournies par le client)

À partir de la version 2019-02-02, les en-têtes suivants peuvent être spécifiés sur la demande de chiffrement d’un objet blob chiffré avec une clé fournie par le client. Le chiffrement avec une clé fournie par le client (et l’ensemble d’en-têtes correspondant) est facultatif.

En-tête de requête	Description
`x-ms-encryption-key`	Obligatoire. Clé de chiffrement AES-256 encodée en Base64.
`x-ms-encryption-key-sha256`	Obligatoire. Hachage SHA256 encodé en Base64 de la clé de chiffrement.
`x-ms-encryption-algorithm: AES256`	Obligatoire. Spécifie l’algorithme à utiliser pour le chiffrement. La valeur de cet en-tête doit être définie `AES256`.

Corps de la demande

Le corps de la demande contient le contenu de la page.

Exemple de requête

  
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

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie renvoie le code d'état 201 (Créé).

Pour plus d’informations sur les codes status, consultez Codes d’état et d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut aussi inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

Syntaxe	Description
`ETag`	ETag pour l'objet blob. Si la version de la demande est 2011-08-18 et versions ultérieures, la valeur ETag est placée entre guillemets. L'ETag peut être utilisé pour effectuer une opération conditionnelle `Put Page From URL` en spécifiant sa valeur pour l'en-tête de demande `If-Match` ou `If-None-Match`.
`Last-Modified`	Date et heure de la dernière modification apportée à l’objet blob. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représenter les valeurs de date/heure dans les en-têtes. Toute opération d'écriture dans l'objet blob (notamment les mises à jour des métadonnées ou des propriétés de l'objet blob), modifie l'heure de la dernière modification de l'objet blob.
`Content-MD5`	Retourné afin que le client puisse case activée pour l’intégrité du contenu du message. La valeur de cet en-tête est calculée par le service Blob. Elle n’est pas nécessairement identique à la valeur spécifiée dans les en-têtes de requête. Pour la version 2019-02-02 ou ultérieure, cet en-tête est retourné uniquement lorsque la requête a cet en-tête.
`x-ms-content-crc64`	Pour la version 2019-02-02 ou ultérieure. Retourné afin que le client puisse case activée pour l’intégrité du contenu du message. La valeur de cet en-tête est calculée par le service Blob. Elle n’est pas nécessairement identique à la valeur spécifiée dans les en-têtes de requête. Cet en-tête est retourné lorsque `x-ms-source-content-md5` l’en-tête n’est pas présent dans la demande.
`x-ms-blob-sequence-number`	Le numéro de séquence actuel pour l'objet blob de pages.
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée, et elle peut être utilisée pour résoudre les problèmes de la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
`x-ms-version`	Indique la version du service Blob utilisée pour exécuter la demande. Cet en-tête est retourné pour les demandes effectuées sur la version 2009-09-19 et ultérieure.
`Date`	Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 et ultérieures. La valeur de cet en-tête est définie sur `true` si le contenu de la demande est correctement chiffré à l’aide de l’algorithme spécifié, et `false` sinon.
`x-ms-encryption-key-sha256`	Version 2019-02-02 et ultérieures. Retourné si la demande a utilisé une clé fournie par le client pour le chiffrement, afin que le client puisse s’assurer que le contenu de la demande est correctement chiffré à l’aide de la clé fournie.
`x-ms-encryption-scope`	Version 2019-02-02 et ultérieures. Retourné si la demande a utilisé une étendue de chiffrement, afin que le client puisse s’assurer que le contenu de la demande est correctement chiffré à l’aide de l’étendue de chiffrement.
`x-ms-client-request-id`	Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête `x-ms-client-request-id` s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête `x-ms-client-request-id` n’est pas présent dans la demande, il ne sera pas présent dans la réponse.

Response body

Aucun.

Exemple de réponse

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

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Put Page From URL comme décrit ci-dessous.

Important

Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes à Stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationPut Page From URL, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rôle intégré le moins privilégié :Contributeur aux données blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour l’accès aux données d’objets blob.

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la SAP.

L’opération Put Page From URL prend en charge trois types de signatures d’accès partagé : sas de délégation d’utilisateur, SAP de service et SAP de compte.

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser Microsoft Entra informations d’identification plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez Microsoft Entra informations d’identification pour créer une sap de délégation d’utilisateur, si possible.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de service ou un jeton SAP de compte ne sont pas autorisés lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de délégation d’utilisateur

Une sap de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra ainsi que par les autorisations spécifiées pour la sap.

L’appel de l’opération à l’aide Put Page From URL d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation Write (w) dans le cadre du jeton SAP de délégation utilisateur.

Pour en savoir plus sur la sap de délégation d’utilisateur, consultez Create une SAP de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une sap de service délègue l’accès à une ressource dans un seul service Stockage Azure, tel que le stockage blob.

L’appel de l’opération à l’aide Put Page From URL d’un jeton SAP délégué à un conteneur ou à une ressource blob nécessite l’autorisation Write (w) dans le cadre du jeton SAP de service.

Pour en savoir plus sur la SAP de service, consultez Create une SAP de service.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Put Page From URL	Objet blob (b)	Objet (o)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Create une SAP de compte.

L’opération Put Page From URL prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée dans la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

L'opération Put Page From URL écrit une plage de pages dans un objet blob de pages. Cette opération ne peut être appelée que sur un objet blob de pages existant. Il ne peut pas être appelé pour créer un objet blob de page, ni sur un objet blob de bloc. L’appel Put Page From URL avec un nom d’objet blob qui n’existe pas actuellement retourne l’erreur BlobNotFound (code HTTP status 404 – Introuvable).

Dans les versions 2020-10-02 et ultérieures, Microsoft Entra autorisation est prise en charge pour la source de l’opération de copie.

Pour créer un objet blob de page, appelez Put Blob et spécifiez le type d’objet blob à créer en tant qu’objet blob de page. Un objet blob de pages peut avoir jusqu’à 8 Tio.

Si l’objet blob a un bail actif, le client doit spécifier un ID de bail valide sur la demande d’écriture d’une page.

Opérations de mise à jour de page

L’appel Put Page From URL effectue une écriture sur place sur l’objet blob de page spécifié. Tout contenu dans la page spécifiée est remplacé par la mise à jour.

Important

Si le serveur expire ou si votre connexion est fermée pendant un Put Page From URL, la page a peut-être été mise à jour ou non. Par conséquent, réessayez la mise à jour jusqu'à ce que vous receviez une réponse indiquant la réussite.

Chaque plage de pages envoyées avec Put Page From URL pour une opération de mise à jour peut avoir une taille maximale de 4 Mio. La plage de début et de fin de la page doivent être alignées avec les limites de 512 octets. Si vous tentez de charger une plage de pages supérieure à 4 Mio, le service retourne status code 413 (Demander une entité trop grande).

Gérer les problèmes de concurrence

Le service Blob gère séquentiellement les écritures simultanées dans les pages qui se chevauchent. Autrement dit, la dernière page traitée par le service détermine le contenu de l’objet blob. Par conséquent, pour garantir l'intégrité du contenu de l'objet blob, le client doit gérer les écritures dans les pages qui se chevauchent en utilisant l'une des approches suivantes :

Vous pouvez vérifier la valeur de l'en-tête de réponse Last-Modified pour chaque appel réussi à Put Page From URL. L’ordre des réponses retournées par le service Blob ne correspond pas nécessairement à l’ordre dans lequel elles ont été exécutées par le service. Mais la valeur de Last-Modified indique toujours l'ordre dans lequel le service a traité les demandes.
Vous pouvez effectuer des mises à jour conditionnellement en fonction de l'ETag de l'objet blob ou de l'heure de la dernière modification en utilisant l'accès concurrentiel optimiste. Cette approche fonctionne correctement si le nombre d'écritures simultanées est relativement faible. Utilisez les en-têtes de demande conditionnels If-Match, If-None-Match, If-Modified-Since et If-Unmodified-Since dans ce cas.
Vous pouvez appeler l’objet blob de bail pour verrouiller l’objet blob contre d’autres écritures pendant une période d’une minute ou plus si le bail est renouvelé.
Vous pouvez utiliser le numéro de séquence de l’objet blob pour vous assurer que la nouvelle tentative d’une demande pour laquelle aucune réponse n’a donné lieu à des mises à jour simultanées. Cette approche est préférable pour les clients qui requièrent des débits élevés pour les écritures de page. il est décrit en détail dans la section suivante.

Utiliser le numéro de séquence de l’objet blob de page pour réessayer les demandes

Lorsqu’un appel à Put Page From URL expire ou ne retourne pas de réponse, il n’existe aucun moyen de savoir avec certitude si la demande a réussi. Vous devez donc réessayer la demande, mais en raison de la nature distribuée des services de stockage Azure, il est possible que la demande d’origine soit traitée une fois que la demande retentée a réussi. La demande d'origine retardée peut remplacer d'autres mises à jour et produire des résultats inattendus. La séquence suivante illustre comment cela peut se produire :

Une Put Page From URL demande d’écriture de la valeur « X » dans la page 0 expire ou ne retourne pas de réponse.
Une demande de nouvelle tentative d'écriture de la valeur « X » dans la page 0 réussit.
Une demande d'écriture de la valeur « Y » dans la page 0 réussit.
La demande d'origine réussit, et écrit la valeur « X » dans la page 0.
La lecture de la page 0 retourne la valeur « X », alors que le client s'attendait à la valeur « Y ».

Ce type de conflit peut se produire lorsque la demande d’origine ne retourne pas de code status compris entre 100 et 499 ou 503 (serveur occupé). Si l'un de ces codes d'état est retourné, vous pouvez savoir si la demande a réussi ou a échoué. Mais si le service retourne un code d'état en dehors de cette plage, il n'existe aucun moyen de savoir l'état de la demande d'origine.

Pour éviter ce type de conflit, vous pouvez utiliser le numéro de séquence de l’objet blob de page pour vous assurer que lorsque vous réessayez une demande, la demande d’origine ne réussit pas par la suite. Pour cela, vous devez incrémenter le numéro de séquence avant de retenter la demande d'origine. Vous pouvez ensuite utiliser les en-têtes de numéros de séquence conditionnels pour vous assurer que la demande échoue si son numéro de séquence ne correspond pas au numéro de séquence attendu. La séquence suivante illustre cette approche :

Le client crée un objet blob de page avec Put Blob et définit son numéro de séquence sur 0.
Une Put Page From URL demande d’écriture de la valeur « X » à la page 0 avec l’en-tête if-sequence-number-lt défini sur 1 expirer ou ne retourne pas de réponse.
Le client appelle Set Blob Properties pour mettre à jour le numéro de séquence à 1.
Demande de nouvelle tentative d’écriture de la valeur « X » à la page 0 avec if-sequence-number-lt la valeur réussie 2 .
Une demande d’écriture de la valeur « Y » à la page 0 avec if-sequence-number-lt la valeur réussie 2 .
La requête d’origine est finalement traitée, mais elle échoue, car elle spécifie la condition selon laquelle le numéro de séquence doit être inférieur à 11 (autrement dit, l’en-tête if-sequence-num-lt est défini sur ). L'erreur est SequenceNumberConditionNotMet (code d'état HTTP 412 – Échec de la précondition).
La lecture de la page 0 retourne la valeur attendue « Y ».

Voir aussi

Autoriser les demandes dans le Stockage Azure
Codes d’état et d’erreur
Définir des délais d’attente pour les opérations de service Blob

Partager via