Put Block List

Der Put Block List-Vorgang schreibt ein BLOB, indem die Liste der Block-IDs angegeben wird, aus denen sich das BLOB zusammensetzt. Um als Teil eines Blobs geschrieben zu werden, muss ein Block in einem vorherigen Put Block-Vorgang erfolgreich auf den Server geschrieben worden sein.

Sie können Put Block List aufrufen, um ein BLOB zu aktualisieren, indem Sie nur die Blöcke mit Änderungen hochladen und anschließend für die neuen und vorhandenen Blöcke einen Commit ausführen. Dies erreichen Sie, indem Sie angeben, ob für einen Block aus der Liste der Blöcke mit ausgeführtem Commit oder der Liste der Blöcke ohne ausgeführten Commit ein Commit ausgeführt werden soll, oder ob für die zuletzt hochgeladene Version des Blocks ein Commit ausgeführt werden soll, je nachdem, in welcher Liste der Block enthalten ist.

Anforderung

Die Put Block List-Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

Anforderungs-URI für PUT-Methode HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

URI des emulierten Speicherdiensts

Wenn Sie eine Anforderung für den emulierten Speicherdienst ausführen, geben Sie den Emulatorhostnamen und den Port des Blob-Diensts mit 127.0.0.1:10000 an, gefolgt vom Namen des emulierten Speicherkontos:

Anforderungs-URI für PUT-Methode HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist HTTP/1.1

Der Speicheremulator unterstützt nur Blobgrößen bis zu 2 GiB.

Weitere Informationen finden Sie unter Verwenden des Azure Storage Emulator für Entwicklung und Tests.

URI-Parameter

Im Anforderungs-URI können die folgenden zusätzlichen Parameter angegeben werden.

Parameter BESCHREIBUNG
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blobdienstvorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Anforderungsheader 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 (Coordinated Universal Time, 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 für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage Services.
Content-Length Erforderlich. Die Länge des Anforderungsinhalts in Byte. Dieser Header bezieht sich auf die Inhaltslänge der Liste der Blöcke, nicht auf die Länge des Blobs selbst.
Content-MD5 Optional. Ein MD5-Hash des Anforderungsinhalts. Mithilfe des Hash wird die Integrität des Anforderungsinhalts während der Übertragung überprüft. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Dieser Header ist dem Anforderungsinhalt und nicht dem Inhalt des Blobs selbst zugeordnet.
x-ms-content-crc64 Optional. Ein crc64-Hash des Anforderungsinhalts. Mithilfe des Hash wird die Integrität des Anforderungsinhalts während der Übertragung überprüft. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Dieser Header ist dem Anforderungsinhalt und nicht dem Inhalt des Blobs selbst zugeordnet.

Wenn sowohl Content-MD5- als auch x-ms-content-crc64-Header vorhanden sind, schlägt die Anforderung mit dem Fehler 400 (Ungültige Anforderung) fehl.

Dieser Header wird in den Versionen 2019-02-02 oder höher unterstützt.
x-ms-blob-cache-control Optional. Legt das Cachesteuerelement des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.
x-ms-blob-content-type Optional. Legt den Inhaltstyp des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn der Inhaltstyp nicht angegeben ist, wird er auf den Standardwert application/octet-stream festgelegt.
x-ms-blob-content-encoding Optional. Legt die Inhaltscodierung des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.
x-ms-blob-content-language Optional. Legt die Sprache für den Inhalt des BLOB fest. Sofern angegeben, wird diese Eigenschaft mit dem BLOB gespeichert und mit einer Leseanforderung zurückgegeben.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.
x-ms-blob-content-md5 Optional. Ein MD5-Hash des BLOB-Inhalts. Dieser Hash wird nicht überprüft, da die Hashes für die einzelnen Blöcke beim Hochladen der einzelnen Blöcke überprüft wurden.

Der Vorgang Blob abrufen gibt den Wert dieses Headers im Content-MD5-Antwortheader zurück.

Wenn diese Eigenschaft nicht mit der Anforderung angegeben ist, wird sie für das BLOB gelöscht, wenn die Anforderung erfolgreich ausgeführt wurde.
x-ms-meta-name:value Optional. Benutzerdefinierte Name-Wert-Paare, die dem BLOB zugeordnet sind.

Ab Version 2009-09-19 müssen Metadatennamen den Benennungsregeln für C#-Bezeichnerentsprechen.
x-ms-encryption-scope Optional. Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Blobs verwendet werden soll. Dieser Wert muss mit dem Verschlüsselungsbereich übereinstimmen, der zum Verschlüsseln aller Blöcke verwendet wird, für die ein Commit ausgeführt wird. Dieser Header wird in den Versionen 2019-02-02 oder höher unterstützt.
x-ms-tags Optional. Legt die angegebenen abfragezeichenfolgencodierten Tags für das Blob fest. Weitere Informationen finden Sie in den Hinweisen. Unterstützt in Version 2019-12-12 und höher.
x-ms-lease-id:<ID> Erforderlich, wenn das BLOB über eine aktive Lease 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-client-request-id Optional. Stellt einen vom Client generierten, nicht transparenten Wert mit einem Zeichenlimit von 1 KiB bereit, der in den Analyseprotokollen aufgezeichnet wird, wenn die Protokollierung der Speicheranalyse aktiviert ist. Es wird empfohlen, diesen Header für das Korrelieren clientseitiger Aktivitäten mit vom Server empfangenen Anforderungen zu verwenden. Weitere Informationen finden Sie unter Informationen Storage Analytics-Protokollierung und Azure-Protokollierung: Verwenden von Protokollen zum Nachverfolgen Storage Anforderungen.
x-ms-blob-content-disposition Optional. Legt den Content-Disposition-Header des BLOBs fest. Dieser ist für die Version 2013-08-15 und höher verfügbar.

Das Feld mit dem Content-Disposition-Header enthält zusätzliche Informationen darüber, wie die Antwortnutzlast verarbeitet werden soll, und kann auch verwendet werden, um zusätzliche Metadaten anzufügen. Wenn der Parameter auf attachment festgelegt ist, bedeutet dies, dass der Benutzer-Agent nicht die Antwort, sondern stattdessen das Dialogfeld Speichern unter anzeigen soll.

Die Antwort der Vorgänge Get Blob und Get Blob Properties enthält den content-disposition-Header.
x-ms-access-tier Optional. Version 2018-11-09 und neuer. Gibt die Ebene an, die für ein Blob festgelegt werden soll. Für Blockblobs, die in Blob Storage- oder Allgemein v2-Konten nur mit Version 2018-11-09 und neuer unterstützt werden. Gültige Werte für Blockblobebenen sind Hot / Cool / Archive . Ausführliche Informationen zum Blockblob-Tiering finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".
x-ms-immutability-policy-until-date Version 2020-06-12 und neuer. Gibt das Fürbehaltungsdatum an, das für das Blob festgelegt werden soll. Dies ist das Datum, bis zu dem das Blob vor dem Ändern oder Löschen geschützt werden kann. Folgt dem RFC1123-Format.
x-ms-immutability-policy-mode Version 2020-06-12 und neuer. Gibt den Unveränderlichkeitsrichtlinie-Modus an, der für das Blob festgelegt werden soll. Gültige Werte sind unlocked / locked . unlocked gibt an, dass der Benutzer die Richtlinie ändern kann, indem er die Beibehaltungsdauer bis zum Datum erhöht oder verringert. locked gibt an, dass diese Aktionen nicht zulässig sind.
x-ms-legal-hold Version 2020-06-12 und neuer. Gibt die gesetzliche Zurückbehalten-Eigenschaft an, die für das Blob festgelegt werden soll. Gültige Werte sind true/false .

Dieser Vorgang unterstützt zudem die Verwendung von bedingten Headern zum Ausführen eines Commits für die Blockliste nur dann, wenn eine bestimmte Bedingung erfüllt ist. Weitere Informationen finden Sie unter Specifying Conditional Headers for Blob Service Operations (Angeben von bedingten Headern für Vorgänge des Blob-Diensts).

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 mit einem vom Kunden bereitgestellten Schlüssel zu verschlüsseln. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und dem entsprechenden Satz von Headern) ist optional.

Anforderungsheader 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.

Anforderungstext

Im Anforderungstext können Sie angeben, welche Blockliste der Blob-Dienst für den angeforderten Block überprüfen soll. Auf diese Weise können Sie ein vorhandenes Blob aktualisieren, indem Sie einzelne Blöcke einfügen, ersetzen oder löschen, anstatt das gesamte Blob neu zu laden. Sobald Sie den geänderten Block bzw. die geänderten Blöcke hochgeladen haben, können Sie einen Commit einer neuen Version des BLOB ausführen, indem einen Commit für die neuen Blöcke und die vorhandenen, beizubehaltenden Blöcke ausführen.

Zum Aktualisieren eines BLOB können Sie angeben, dass der Dienst in der Liste der Blöcke mit ausgeführtem Commit, in der Liste der Blöcke ohne ausgeführten Commit oder zuerst in der Liste der Blöcke ohne ausgeführten Commit und anschließend in der Liste der Blöcke mit ausgeführtem Commit nach einer Block-ID suchen soll. Geben Sie zum Festlegen der gewünschten Vorgehensweise wie folgt die Block-ID im entsprechenden XML-Element im Anforderungstext an:

  • Geben Sie die Block-ID im Committed-Element an, um anzugeben, dass der Blob-Dienst nur die Liste der Blöcke mit ausgeführtem Commit nach dem benannten Block durchsuchen soll. Wird der Block nicht in der Liste der Blöcke mit ausgeführtem Commit gefunden, wird er nicht als Teil des BLOB geschrieben, und der Blob-Dienst gibt Statuscode 400 (Ungültige Anforderung) zurück.

  • Geben Sie die Block-ID im Uncommitted-Element an, um anzugeben, dass der Blob-Dienst nur die Liste der Blöcke ohne ausgeführten Commit nach dem benannten Block durchsuchen soll. Wird der Block nicht in der Liste der Blöcke ohne ausgeführten Commit gefunden, wird er nicht als Teil des BLOB geschrieben, und der Blob-Dienst gibt Statuscode 400 (Ungültige Anforderung) zurück.

  • Geben Sie die Block-ID im Latest-Element an, um anzugeben, dass der Blob-Dienst zuerst die Liste der Blöcke ohne ausgeführten Commit durchsuchen soll. Wird der Block nicht in der Liste der Blöcke ohne ausgeführten Commit gefunden, handelt es sich bei dieser Version des Blocks um die aktuelle Version, die in das BLOB geschrieben werden sollte. Wird der Block nicht in der Liste der Blöcke ohne ausgeführten Commit gefunden, durchsucht der Dienst die Liste der Blöcke mit ausgeführtem Commit nach dem benannten Block und schreibt den Block in das BLOB, sofern er gefunden wird.

Der Anforderungstext für diese Version von Put Block List verwendet folgendes XML-Format:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>  
  

Beispiel für eine Anforderung

Zur Veranschaulichung von Put Block List wird angenommen, dass drei Blöcke hochgeladen wurden, für die ein Commit ausgeführt werden soll. Im folgenden Beispiel wird ein Commit für ein neues BLOB ausgeführt. Dabei wird angegeben, dass die neueste Version jedes aufgelisteten Blocks verwendet werden soll. Dabei muss nicht bekannt sein, ob bereits ein Commit für diese Blöcke ausgeführt wurde.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>  
  

Nehmen wir als Nächstes an, dass Sie das BLOB aktualisieren möchten. Das neue BLOB weist die folgenden Änderungen auf:

  • Ein neuer Block mit der ID ANAAAA==. Dieser Block muss zuerst mit einem Aufruf von Put Block hochgeladen werden und wird bis zum Aufruf von in der Blockliste ohneCommitted Put Block List angezeigt.

  • Eine aktualisierte Version des Blocks mit der ID AZAAAA==. Dieser Block muss zuerst mit einem Aufruf von Put Block hochgeladen werden und wird bis zum Aufruf von in der Blockliste ohneCommitted Put Block List angezeigt.

  • Entfernen des Blocks mit der ID AAAAAA==. Angesichts des Umstands, dass dieser Block nicht im nächsten Aufruf von Put Block List enthalten ist, wird der Block effektiv aus dem BLOB entfernt.

Im folgenden Beispiel wird der Aufruf von Put Block List veranschaulicht, durch den das BLOB aktualisiert wird:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>  
  

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben.

Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann außerdem weitere HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwort Beschreibungen
ETag Das Entitätstag enthält einen Wert, den der Client zum Ausführen von bedingten GET/PUT-Vorgängen mit dem If-Match-Anforderungsheader verwenden kann. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.
Last-Modified Datum/Uhrzeit der letzten Änderung des BLOB. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Representation of Date-Time Values in Headers.

Durch jeden Vorgang, der das BLOB ändert, einschließlich eines Updates der Metadaten oder Eigenschaften des BLOB, wird der Zeitpunkt der letzten Änderung aktualisiert.
Content-MD5 Dieser Header wird zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Dieser Header verweist auf den Inhalt der Anforderung (d. h. in diesem Fall auf die Liste der Blöcke) und nicht auf den Inhalt des BLOB selbst. Für Die Versionen 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 die Versionen 2019-02-02 und höher wird dieser Header zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Dieser Header verweist auf den Inhalt der Anforderung (d. h. in diesem Fall auf die Liste der Blöcke) und nicht auf den Inhalt des BLOB selbst.

Dieser Header wird zurückgegeben, Content-md5 wenn der Header in der Anforderung nicht vorhanden ist.
x-ms-request-id Dieser Header identifiziert die erfolgte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
x-ms-version Gibt die Version des Blob-Diensts an, der zum Ausführen der Abfrage verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.
Date Ein vom Dienst generierter Datums-/Uhrzeitwert in UTC, der angibt, wann die Antwort initiiert wurde.
x-ms-request-server-encrypted: true/false Version 2015-12-11 oder neuer. Der Wert dieses Headers wird auf festgelegt, wenn der Inhalt der Anforderung erfolgreich mit dem angegebenen Algorithmus verschlüsselt true wurde, false andernfalls .
x-ms-encryption-key-sha256 Version 2019-02-02 oder neuer. Dieser Header wird zurückgegeben, wenn die Anforderung einen vom Kunden bereitgestellten Schlüssel für die Verschlüsselung verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung erfolgreich mit dem bereitgestellten Schlüssel verschlüsselt wird.
x-ms-encryption-scope Version 2019-02-02 oder neuer. Dieser Header wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung erfolgreich mithilfe des Verschlüsselungsbereichs verschlüsselt wird.
x-ms-version-id: <DateTime> Version 2019-12-12 und neuer. Dieser Header gibt einen nicht transparenten DateTime Wert zurück, der das Blob eindeutig identifiziert. Der Wert dieses Headers gibt die Version des Blobs an und kann in nachfolgenden Anforderungen für den Zugriff auf das Blob verwendet werden.
x-ms-client-request-id Dieser Header kann zur Problembehandlung von Anforderungen und entsprechenden Antworten verwendet werden. Der Wert dieses Headers entspricht dem Wert des Headers, wenn er in der Anforderung vorhanden ist und der Wert mindestens x-ms-client-request-id 1.024 sichtbare ASCII-Zeichen beträgt. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>  

Autorisierung

Dieser Vorgang kann vom Kontobesitzer und von einem Benutzer mit einer SAS (Shared Access Signature) aufgerufen werden, der über die Berechtigung verfügt, in dieses BLOB oder den Container zu schreiben.

Wenn eine Anforderung Tags mit dem Anforderungsheader angibt, muss der Aufrufer die Autorisierungsanforderungen des x-ms-tags Vorgangs "Blobtags festlegen" erfüllen.

Hinweise

Der Put Block List-Vorgang erzwingt die Reihenfolge, in der Blöcke zusammengestellt werden, um ein BLOB zu erstellen.

In der Liste der Blöcke kann ein und dieselbe Block-ID mehrmals angegeben werden. Wenn eine Block-ID mehrmals angegeben ist, stellt sie den Bereich von Bytes an jeder dieser Positionen in der Liste der Blöcke für das endgültige BLOB mit ausgeführtem Commit dar. Wenn eine Block-ID mehr als einmal in der Liste enthalten ist, müssen beide Instanzen der Block-ID innerhalb derselben Liste der Blöcke angegeben werden. Das heißt, beide Instanzen müssen im Committed-Element, im Uncommitted-Element oder im Latest-Element angegeben werden.

Mit Put Block List können Sie ein vorhandenes BLOB ändern, indem Sie einzelne Blöcke einfügen, aktualisieren oder löschen, ohne dass das gesamte BLOB erneut hochgeladen werden muss. Sie können Block-IDs aus der aktuellen Liste der Blöcke mit ausgeführtem Commit und der Liste der Blöcke ohne ausgeführten Commit angeben, um ein neues BLOB zu erstellen oder um den vorhandenen Inhalt eines BLOB zu aktualisieren. Auf diese Weise können Sie ein Blob aktualisieren, indem Sie einige neue Blöcke aus der Blockliste ohneCommitted angeben, und den Rest aus der Liste der Zugesicherten Blöcke, die bereits Teil des vorhandenen Blobs sind.

Wenn eine Block-ID im Latest-Element angegeben ist und die gleiche Block-ID in der Liste der Blöcke mit ausgeführtem Commit und der Liste der Blöcke ohne ausgeführten Commit vorhanden ist, wird von Put Block List ein Commit für den Block aus der Liste der Blöcke ohne ausgeführten Commit ausgeführt. Wenn die Block-ID in der Liste der Blöcke mit ausgeführtem Commit, jedoch nicht in der Liste der Blöcke ohne ausgeführten Commit enthalten ist, führt Put Block List einen Commit für den Block aus der Liste der Blöcke mit ausgeführtem Commit aus.

Jeder Block in einem Blockblob kann eine andere Größe haben. Ein Blockblob kann maximal 50.000 Blöcke mit einem Committed enthalten. Die maximale Anzahl von Blöcken ohneCommitted, die einem Blob zugeordnet sein können, beträgt 100.000. In der folgenden Tabelle werden die maximalen Block- und Blobgrößen beschrieben, die nach Dienstversion zulässig sind:

Dienstversion Maximale Blockgröße (über Put Block) Maximale Blob-Größe (über Put Block-Liste) Maximale Blob-Größe über einen einzelnen Schreibvorgang (über Put Blob)
Ab Version 2019-12-12 4.000 MiB Ungefähr 190,7 TiB (4-000 MiB · 50.000 Blöcke) 5000 MiB (Vorschau)
Version 2016-05-31 bis Version 2019-07-07 100 MiB Ungefähr 4,75 TiB (100 MiB X 50.000 Blöcke) 256 MiB
Versionen vor 2016-05-31 4 MiB Ungefähr 195 GiB (4 MiB X 50.000 Blöcke) 64 MiB

Wenn Sie Put Block List aufrufen, um ein vorhandenes BLOB zu aktualisieren, werden die vorhandenen Eigenschaften und Metadaten des BLOB überschrieben. Alle vorhandenen Momentaufnahmen werden jedoch mit dem BLOB beibehalten. Sie können mithilfe der bedingten Anforderungsheader den Vorgang nur dann ausführen, wenn eine bestimmte Bedingung erfüllt ist.

Wenn der Put Block List-Vorgang aufgrund eines fehlenden Blocks fehlschlägt, müssen Sie den fehlenden Block hochladen.

Alle Blöcke ohne ausgeführten Commit werden vom Garbage Collector erfasst, wenn für das BLOB innerhalb einer Woche nach dem letzten erfolgreichen Put Block-Vorgang keine erfolgreichen Aufrufe von Put Block List oder Put Block erfolgen. Wenn Put Blob für das Blob aufgerufen wird, werden alle Blöcke, für die keinCommitted-Block erstellt wurde, vom Garbage Collection-Dienst erfasst.

Wenn Tags im Header bereitgestellt x-ms-tags werden, müssen sie abfragezeichenfolgencodiert sein. Tagschlüssel und -werte müssen den Namens- und Längenanforderungen entsprechen, wie unter Festlegen von Blobtags angegeben. Darüber hinaus kann x-ms-tags der Header Tags mit einer Größe von bis zu 2 KiB enthalten. Wenn weitere Tags erforderlich sind, verwenden Sie den Vorgang Blobtags festlegen.

Wenn das BLOB über eine aktive Lease verfügt, muss der Client zum Ausführen eines Commits der Liste der Blöcke eine gültige Lease-ID in der Anforderung angeben. Wenn der Client keine Lease-ID oder eine ungültige Lease-ID angibt, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) zurück. Wenn der Client eine Lease-ID angibt, aber das BLOB nicht über eine aktive Lease verfügt, gibt der Blob-Dienst ebenfalls Statuscode 412 (Vorbedingung nicht erfüllt) zurück. Wenn der Client eine Lease-ID für ein BLOB angibt, das noch nicht vorhanden ist, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) für Anforderungen zurück, die für Version 2013-08-15 und höher ausgeführt werden; für frühere Versionen gibt der Blob-Dienst den Statuscode 201 (Erstellt) zurück.

Wenn das BLOB über eine aktive Lease verfügt und Sie Put Block List zum Aktualisieren des BLOB aufrufen, wird die Lease für das aktualisierte BLOB beibehalten.

Put Block List ist nur für Block-BLOBs anwendbar. Der Aufruf von Put Block List für ein Seitenblob führt zum Statuscode 400 (Ungültige Anforderung).

Beim Überschreiben eines archivierten Blobs kommt es zu einem Fehler, und das Überschreiben eines Blobs erbt die Ebene vom alten Blob, wenn hot / cool kein x-ms-access-tier-Header bereitgestellt wird.

Weitere Informationen

Grundlegendes zu Blockblobs, Anfügeblobs und Seitenblobs
Autorisieren von Anforderungen für Azure Storage
Status- und Fehlercodes
Blob-Dienstfehlercodes
Festlegen von Timeouts für Blob-Dienstvorgänge