Freigeben über


Seite aus URL einfügen

Der Put Page From URL Vorgang schreibt einen Seitenbereich in ein Seitenblob, in dem der Inhalt aus einer URL gelesen wird. Diese API ist ab Version 2018-11-09 verfügbar.

Anfrage

Sie können die Put Page From URL Anforderung wie folgt erstellen. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

Anforderungs-URI der PUT-Methode HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung an den emulierten Speicherdienst senden, geben Sie den Hostnamen des Emulators und den Port des Blob-Diensts als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

Anforderungs-URI der PUT-Methode HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können die folgenden zusätzlichen Parameter für den Anforderungs-URI angeben:

Parameter BESCHREIBUNG
timeout Wahlfrei. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob-Dienstvorgänge.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungs-Kopfzeile BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
Range Entweder Range oder x-ms-range ist erforderlich.

Gibt den Bereich der Bytes an, die als Seite geschrieben werden sollen. Sowohl der Anfang als auch das Ende des Bereichs müssen angegeben werden. Dieser Header wird durch die HTTP/1.1-Protokollspezifikationdefiniert.

Bei einem Seitenaktualisierungsvorgang kann der Seitenbereich bis zu 4 MiB groß sein.

Da Seiten an 512-Byte-Grenzen ausgerichtet werden müssen, muss der Startoffset einen Modul von 512 und der Endoffset einen Modul von 512 – 1 betragen. Beispiele für gültige Bytebereiche sind 0-511, 512-1023 usw.

Der Blob-Dienst akzeptiert nur einen einzelnen Bytebereich für den Range Header, und der Bytebereich muss im folgenden Format angegeben werden: bytes=startByte-endByte.

Wenn sowohl Range als auch x-ms-range angegeben werden, verwendet der Dienst den Wert x-ms-range. Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blob-Dienstvorgänge.
x-ms-range Entweder Range oder x-ms-range ist erforderlich.

Gibt den Bereich der Bytes an, die als Seite geschrieben werden sollen. Sowohl der Anfang als auch das Ende des Bereichs müssen angegeben werden. Dieser Header wird durch die HTTP/1.1-Protokollspezifikationdefiniert.

Der Seitenbereich kann bis zu 4 MiB groß sein.

Da Seiten an 512-Byte-Grenzen ausgerichtet werden müssen, muss der Startoffset einen Modul von 512 und der Endoffset einen Modul von 512 – 1 betragen. Beispiele für gültige Bytebereiche sind 0-511, 512-1023 usw.

Der Blob-Dienst akzeptiert nur einen einzelnen Bytebereich für den x-ms-range Header, und der Bytebereich muss im folgenden Format angegeben werden: bytes=startByte-endByte.

Wenn sowohl Range als auch x-ms-range angegeben werden, verwendet der Dienst den Wert x-ms-range. Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blob-Dienstvorgänge.
Content-Length Erforderlich. Gibt die Anzahl der Im Anforderungstext übertragenen Bytes an. Der Wert dieses Headers muss auf Null gesetzt werden. Wenn die Länge nicht Null ist, schlägt der Vorgang mit dem Statuscode 400 (Ungültige Anforderung) fehl.
x-ms-copy-source:name Erforderlich. Gibt die URL des Quellblobs an. Bei dem Wert kann es sich um eine URL mit einer Länge von bis zu 2 KiB handeln, die ein Blob angibt. Der Wert sollte URL-codiert sein, wie er in einem Anforderungs-URI angezeigt wird. Das Quellblob muss entweder öffentlich sein oder über eine Shared Access Signature autorisiert sein. Wenn das Quellblob öffentlich ist, ist keine Autorisierung erforderlich, um den Vorgang auszuführen. Hier sind einige Beispiele für Quellobjekt-URLs:

- 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> Wahlfrei. Gibt das Berechtigungsschema und die Signatur für die Kopierquelle an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Für Microsoft Entra wird nur ein Schema-Bearer unterstützt.
Dieser Header wird in Version 2020-10-02 und höher unterstützt.
x-ms-source-range Lädt die Bytes des Blobs in der Quell-URL im angegebenen Bereich hoch. Sowohl der Anfang als auch das Ende des Bereichs müssen angegeben werden. Dieser Header wird durch die HTTP/1.1-Protokollspezifikationdefiniert.

Der Seitenbereich kann bis zu 4 MiB groß sein.

Der Blob-Dienst akzeptiert nur einen einzelnen Bytebereich für den x-ms-source-range Header, und der Bytebereich muss im folgenden Format angegeben werden: bytes=startByte-endByte.

Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blob-Dienstvorgänge .
x-ms-source-content-md5 Wahlfrei. Ein MD5-Hash des Seiteninhalts aus dem URI. Dieser Hash wird verwendet, um die Integrität der Seite während des Transports der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der von der Copy-Source eingegangen ist, mit diesem Headerwert.

Hinweis: Dieser MD5-Hash wird nicht mit dem Blob gespeichert.

Wenn die beiden Hashes nicht übereinstimmen, schlägt der Vorgang mit dem Fehlercode 400 (Ungültige Anforderung) fehl.
x-ms-source-content-crc64 Wahlfrei. Ein CRC64-Hash des Seiteninhalts aus dem URI. Dieser Hash wird verwendet, um die Integrität der Seite während des Transports der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der von der Copy-Source eingegangen ist, mit diesem Headerwert.

Hinweis: Dieser CRC64-Hash wird nicht mit dem Blob gespeichert.

Wenn die beiden Hashes nicht übereinstimmen, schlägt der Vorgang mit dem Fehlercode 400 (Ungültige Anforderung) fehl.

Wenn sowohl als auch x-ms-source-content-md5x-ms-source-content-crc64 Header vorhanden sind, schlägt die Anforderung mit einem 400 (Bad Request) fehl.

Dieser Header wird in Version 2019-02-02 und höher unterstützt.
x-ms-lease-id:<ID> Erforderlich, wenn das Blob über eine aktive Pacht verfügt. Um diesen Vorgang für ein Blob mit einer aktiven Lease auszuführen, geben Sie die gültige Lease-ID für diesen Header an.
x-ms-if-sequence-number-le: <num> Wahlfrei. Wenn die Sequenznummer des Blobs kleiner oder gleich dem angegebenen Wert ist, wird die Anforderung fortgesetzt. Andernfalls tritt ein Fehler mit dem Fehler SequenceNumberConditionNotMet auf (HTTP-Statuscode 412 – Vorbedingung fehlgeschlagen).
x-ms-if-sequence-number-lt: <num> Wahlfrei. Wenn die Sequenznummer des Blobs kleiner als der angegebene Wert ist, wird die Anforderung fortgesetzt. Andernfalls tritt ein Fehler mit dem Fehler SequenceNumberConditionNotMet auf (HTTP-Statuscode 412 – Vorbedingung fehlgeschlagen).
x-ms-if-sequence-number-eq: <num> Wahlfrei. Wenn die Sequenznummer des Blobs gleich dem angegebenen Wert ist, wird die Anforderung fortgesetzt. Andernfalls tritt ein Fehler mit dem Fehler SequenceNumberConditionNotMet auf (HTTP-Statuscode 412 – Vorbedingung fehlgeschlagen).
If-Modified-Since Wahlfrei. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn das Blob seit dem angegebenen Datum/der angegebenen Uhrzeit geändert wurde. Wenn das Blob nicht geändert wurde, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück.
If-Unmodified-Since Wahlfrei. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn das Blob seit dem angegebenen Datum/der angegebenen Uhrzeit nicht geändert wurde. Wenn das Blob geändert wurde, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück.
If-Match Wahlfrei. Ein ETag-Wert. Geben Sie einen ETag-Wert für diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn der ETag-Wert des Blobs mit dem angegebenen Wert übereinstimmt. Wenn die Werte nicht übereinstimmen, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück.
If-None-Match Wahlfrei. Ein ETag-Wert.

Geben Sie einen ETag-Wert für diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn der ETag-Wert des Blobs nicht mit dem angegebenen Wert übereinstimmt. Wenn die Werte identisch sind, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück.
x-ms-encryption-scope Wahlfrei. Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Quellinhalts verwendet werden soll. Dieser Header wird in Version 2019-02-02 und höher unterstützt.
x-ms-client-request-id Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem 1-Kibibyte-Zeichenlimit (KiB) bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen von Azure Blob Storage.
x-ms-file-request-intent Erforderlich, wenn x-ms-copy-source es sich bei dem Header um eine Azure-Datei-URL handelt und x-ms-copy-source-authorization der Header ein OAuth-Token angibt. Zulässiger Wert ist backup. Dieser Header gibt an, dass die Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action oder Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action gewährt werden sollen, wenn sie in der RBAC-Richtlinie enthalten sind, die der Identität zugewiesen ist, die mithilfe des x-ms-copy-source-authorization-Headers autorisiert ist. Verfügbar für Version 2025-07-05 und höher.

Dieser Vorgang unterstützt auch die Verwendung von bedingten Headern, um den Vorgang nur auszuführen, wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob-Dienstvorgänge.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Ab Version 2019-02-02 können die folgenden Header in der Anforderung angegeben werden, um ein Blob zu verschlüsseln, das mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt wurde. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und dem entsprechenden Satz von Headern) ist optional.

Anforderungs-Kopfzeile BESCHREIBUNG
x-ms-encryption-key Erforderlich. Der base64-codierte AES-256-Verschlüsselungsschlüssel.
x-ms-encryption-key-sha256 Erforderlich. Der base64-codierte SHA256-Hash des Verschlüsselungsschlüssels.
x-ms-encryption-algorithm: AES256 Erforderlich. Gibt den Algorithmus an, der für die Verschlüsselung verwendet werden soll. Der Wert dieses Headers muss auf AES256 festgelegt sein.

Anfragekörper

Der Anforderungstext enthält den Inhalt der Seite.

Musteranforderung

  
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  
  

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 201 (Erstellt) zurück.

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortkopfzeilen

Die Antwort für diesen Vorgang enthält die folgenden Header. Die Antwort kann auch zusätzliche Standard-HTTP-Header enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Syntax BESCHREIBUNG
ETag Das ETag für das Blob. Wenn die Anforderungsversion 2011-08-18 und höher ist, wird der ETag-Wert in Anführungszeichen gesetzt. Das ETag kann verwendet werden, um einen bedingten Put Page From URL Vorgang auszuführen, indem sein Wert für den If-Match Anforderungsheader oder If-None-Match angegeben wird.
Last-Modified Das Datum und die Uhrzeit der letzten Änderung des Blobs. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.

Jeder Schreibvorgang für das Blob, einschließlich Aktualisierungen der Metadaten oder Eigenschaften des Blobs, ändert den Zeitpunkt der letzten Änderung des Blobs.
Content-MD5 Wird zurückgegeben, sodass der Client auf die Integrität von Nachrichteninhalten überprüfen kann. Der Wert dieses Headers wird vom Blob-Dienst berechnet. Er ist nicht notwendigerweise identisch mit dem Wert, der in den Anforderungsheadern angegeben ist. Für Version 2019-02-02 oder höher wird dieser Header nur zurückgegeben, wenn die Anforderung über diesen Header verfügt.
x-ms-content-crc64 Für Version 2019-02-02 oder höher. Wird zurückgegeben, sodass der Client auf die Integrität von Nachrichteninhalten überprüfen kann. Der Wert dieses Headers wird vom Blob-Dienst berechnet. Er ist nicht notwendigerweise identisch mit dem Wert, der in den Anforderungsheadern angegeben ist.

Dieser Header wird zurückgegeben, wenn x-ms-source-content-md5 der Header in der Anforderung nicht vorhanden ist.
x-ms-blob-sequence-number Die aktuelle Sequenznummer für das Seitenblob.
x-ms-request-id Identifiziert die anforderung eindeutig, die durchgeführt wurde, und kann verwendet werden, um die Anforderung zu behandeln. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Gibt die Blob-Dienstversion an, die zum Ausführen der Anforderung verwendet wurde. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher vorgenommen wurden.
Date Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
x-ms-request-server-encrypted: true/false Version 2015-12-11 und höher. Der Wert dieses Headers wird auf true festgelegt, wenn der Inhalt der Anforderung mithilfe des angegebenen Algorithmus erfolgreich verschlüsselt wurde, und false auf den anderen Zeitraum.
x-ms-encryption-key-sha256 Version 2019-02-02 und höher. Wird zurückgegeben, wenn für die Anforderung ein vom Kunden bereitgestellter Schlüssel für die Verschlüsselung verwendet wurde, damit der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des bereitgestellten Schlüssels erfolgreich verschlüsselt wird.
x-ms-encryption-scope Version 2019-02-02 und höher. Wird zurückgegeben, wenn für die Anforderung ein Verschlüsselungsbereich verwendet wurde, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des Verschlüsselungsbereichs erfolgreich verschlüsselt wird.
x-ms-client-request-id Kann verwendet werden, um Anfragen und entsprechende Antworten zu behandeln. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id-Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Antwortkörper

Keiner.

Beispielantwort

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  
  

Autorisierung

Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. Sie können den Put Page From URL Vorgang wie unten beschrieben autorisieren.

Von Bedeutung

Microsoft empfiehlt die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Die Microsoft Entra-ID bietet eine bessere Sicherheit und Benutzerfreundlichkeit im Vergleich zur Shared Key-Autorisierung.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine von Azure verwaltete Identität sein. Der Sicherheitsprinzipal wird von der Microsoft Entra-ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann dann verwendet werden, um eine Anforderung gegen den Blob-Dienst zu autorisieren.

Weitere Informationen zur Autorisierung mithilfe der Microsoft Entra-ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Erlaubnisse

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Put Page From URL Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf BLOB-Daten.

Bemerkungen

Der Put Page From URL Vorgang schreibt einen Bereich von Seiten in ein Seitenblob. Dieser Vorgang kann nur für ein vorhandenes Seitenblob aufgerufen werden. Es kann weder aufgerufen werden, um ein neues Seitenblob zu erstellen, noch kann es für ein Blockblob aufgerufen werden. Beim Aufrufen Put Page From URL mit einem Blobnamen, der derzeit nicht vorhanden ist, wird der Fehler BlobNotFound zurückgegeben (HTTP-Statuscode 404 – Nicht gefunden).

In Version 2020-10-02 und höher wird die Microsoft Entra-Autorisierung für die Quelle des Kopiervorgangs unterstützt.

Um ein neues Seitenblob zu erstellen, rufen Sie Put Blob auf , und geben Sie den Typ des Blobs an, das als Seitenblob erstellt werden soll. Ein Seitenblob kann bis zu 8 TiB groß sein.

Wenn das Blob über eine aktive Lease verfügt, muss der Client eine gültige Lease-ID in der Anforderung angeben, um eine Seite zu schreiben.

Vorgänge zum Aktualisieren von Seiten

Durch den Aufruf Put Page From URL wird ein direkter Schreibvorgang für das angegebene Seitenblob ausgeführt. Alle Inhalte auf der angegebenen Seite werden mit dem Update überschrieben.

Von Bedeutung

Wenn für den Server eine Zeitüberschreitung auftritt oder die Verbindung während eines geschlossen Put Page From URLwird, wurde die Seite möglicherweise nicht aktualisiert. Daher sollten Sie das Update so lange wiederholen, bis Sie eine Antwort erhalten, die auf Erfolg hinweist.

Jeder Seitenbereich, mit dem Put Page From URL für einen Aktualisierungsvorgang übermittelt wird, kann bis zu 4 MiB groß sein. Der Start- und Endbereich der Seite muss an den 512-Byte-Grenzen ausgerichtet sein. Wenn Sie versuchen, einen Seitenbereich hochzuladen, der größer als 4 MiB ist, gibt der Dienst den Statuscode 413 (Request Entity Too Large) zurück.

Verwalten von Parallelitätsproblemen

Der Blob-Dienst verarbeitet gleichzeitige Schreibvorgänge auf überlappenden Seiten sequenziell. Das heißt, die letzte Seite, die vom Dienst verarbeitet wird, bestimmt den Inhalt des Blobs. Um die Integrität des Inhalts des Blobs sicherzustellen, sollte der Client daher Schreibvorgänge auf überlappende Seiten mit einem oder mehreren der folgenden Ansätze verarbeiten:

  • Sie können den Wert des Last-Modified Antwortheaders für jeden erfolgreichen Aufruf von Put Page From URLüberprüfen. Die Reihenfolge der Antworten, die vom Blob-Dienst zurückgegeben werden, entspricht nicht unbedingt der Reihenfolge, in der sie vom Dienst ausgeführt wurden. Der Wert von Last-Modified gibt jedoch immer die Reihenfolge an, in der der Dienst die Anforderungen verarbeitet hat.

  • Sie können Aktualisierungen bedingt basierend auf dem ETag des Blobs oder dem Zeitpunkt der letzten Änderung durchführen, indem Sie die optimistische Parallelität verwenden. Dieser Ansatz funktioniert gut, wenn die Anzahl gleichzeitiger Schreibvorgänge relativ gering ist. Verwenden Sie zu diesem Zweck die bedingten If-MatchAnforderungsheader , If-None-Match, If-Modified-Sinceund If-Unmodified-Since .

  • Sie können Lease Blob aufrufen, um das Blob für einen Zeitraum von einer Minute oder länger, wenn die Lease erneuert wird, für andere Schreibvorgänge zu sperren.

  • Sie können die Sequenznummer des Blobs verwenden, um sicherzustellen, dass die Wiederholung einer Anforderung, auf die keine Antwort erfolgte, nicht zu gleichzeitigen Aktualisierungen führt. Dieser Ansatz eignet sich möglicherweise am besten für Clients, die einen hohen Durchsatz für Seitenschreibvorgänge benötigen. Es wird im folgenden Abschnitt ausführlich beschrieben.

Verwenden Sie die Sequenznummer des Seitenblobs, um Anforderungen zu wiederholen

Wenn bei einem Aufruf von Put Page From URL eine Zeitüberschreitung auftritt oder keine Antwort zurückgegeben wird, gibt es keine Möglichkeit, mit Sicherheit zu wissen, ob die Anforderung erfolgreich war. Daher müssen Sie die Anforderung wiederholen, aber aufgrund der verteilten Natur der Azure-Speicherdienste ist es möglich, dass die ursprüngliche Anforderung verarbeitet wird, nachdem die wiederholte Anforderung erfolgreich war. Die verzögerte ursprüngliche Anforderung kann andere Aktualisierungen überschreiben und zu einem unerwarteten Ergebnis führen. Die folgende Sequenz veranschaulicht, wie dies geschehen kann:

  1. Bei einer Put Page From URL Anforderung, den Wert "X" auf Seite 0 zu schreiben, tritt eine Zeitüberschreitung auf oder es wird keine Antwort zurückgegeben.

  2. Eine wiederholte Anforderung, den Wert "X" auf Seite 0 zu schreiben, ist erfolgreich.

  3. Eine Anforderung, den Wert "Y" auf Seite 0 zu schreiben, ist erfolgreich.

  4. Die ursprüngliche Anforderung ist erfolgreich und schreibt den Wert "X" auf Seite 0.

  5. Beim Lesen von Seite 0 wird der Wert "X" zurückgegeben, obwohl der Client zu diesem Zeitpunkt den Wert "Y" erwartet hat.

Diese Art von Konflikt kann auftreten, wenn die ursprüngliche Anforderung keinen Statuscode zwischen 100 und 499 oder 503 (Server ausgelastet) zurückgibt. Wenn einer dieser Statuscodes zurückgegeben wird, können Sie sicher sein, ob die Anforderung erfolgreich war oder fehlgeschlagen ist. Wenn der Dienst jedoch einen Statuscode außerhalb dieses Bereichs zurückgibt, gibt es keine Möglichkeit, den Status der ursprünglichen Anforderung zu ermitteln.

Um diese Art von Konflikt zu vermeiden, können Sie die Sequenznummer des Seitenblobs verwenden, um sicherzustellen, dass die ursprüngliche Anforderung beim Wiederholen einer Anforderung später nicht erfolgreich ausgeführt wird. Zu diesem Zweck sollten Sie die Sequenznummer erhöhen, bevor Sie die ursprüngliche Anforderung wiederholen. Sie können dann die Header für bedingte Sequenznummern verwenden, um sicherzustellen, dass die Anforderung fehlschlägt, wenn die Sequenznummer nicht mit der erwarteten Sequenznummer übereinstimmt. Die folgende Sequenz veranschaulicht diesen Ansatz:

  1. Der Client erstellt ein Seitenblob mit Put Blob und legt die Sequenznummer auf 0 fest.

  2. Eine Put Page From URL Anforderung, den Wert "X" auf Seite 0 zu schreiben, wobei der if-sequence-number-lt Header auf 1 eine Zeitüberschreitung festgelegt ist oder keine Antwort zurückgibt.

  3. Der Client ruft Set Blob Properties auf, um die Sequenznummer auf 1 zu aktualisieren.

  4. Eine wiederholte Anforderung, den Wert "X" auf Seite 0 zu schreiben, wobei if-sequence-number-lt der Wert auf festgelegt ist, 2 ist erfolgreich.

  5. Eine Anforderung, den Wert "Y" auf Seite 0 zu schreiben, wobei if-sequence-number-lt der Wert auf festgelegt ist, 2 ist erfolgreich.

  6. Die ursprüngliche Anforderung wird schließlich verarbeitet, schlägt jedoch fehl, da sie die Bedingung angibt, dass die Sequenznummer kleiner als 1 sein muss (d. h., der if-sequence-num-lt Header ist auf 1). Der Fehler lautet SequenceNumberConditionNotMet (HTTP-Statuscode 412 – Vorbedingung fehlgeschlagen).

  7. Beim Lesen von Seite 0 wird der Erwartungswert von "Y" zurückgegeben.

Siehe auch

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Festlegen von Timeouts für Blob-Dienstvorgänge