Put Block List

Artikel
02/07/2024

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 früheren Put Block-Vorgang erfolgreich auf den Server geschrieben worden sein.

Sie können aufrufen Put Block List , um ein Blob zu aktualisieren, indem Sie nur die Blöcke hochladen, die sich geändert haben, und dann die neuen und vorhandenen Blöcke zusammen commitsieren. Dazu geben Sie an, ob ein Commit für einen Block aus der Commitliste oder aus der Liste nicht gebundener Blöcke oder die zuletzt hochgeladene Version des Blocks, unabhängig davon, zu welcher Liste er gehört, committet werden soll.

Anforderung

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

PUT-Methodenanforderungs-URI	HTTP-Version
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Emulierte Speicherdienstanforderung

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und den Blobdienstport als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

PUT-Methodenanforderungs-URI	HTTP-Version
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist`	HTTP/1.1

Der Speicheremulator unterstützt nur Blobgrößen von bis zu 2 Gibibytes (GiB).

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

URI-Parameter

Sie können im Anforderungs-URI die folgenden zusätzlichen Parameter angeben:

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

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle 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-Speicherdienste.
`Content-Length`	Erforderlich. Die Länge des Anforderungsinhalts in Bytes. Dieser Header bezieht sich auf die Inhaltslänge der Liste der Blöcke, nicht auf das Blob 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 einer 400 (Ungültige Anforderung) fehl. Dieser Header wird ab Version 2019-02-02 unterstützt.
`x-ms-blob-cache-control`	Optional. Legt das Cachesteuerelement des BLOB fest. Wenn diese Eigenschaft angegeben wird, wird sie mit dem Blob gespeichert und mit einer Leseanforderung zurückgegeben. Wenn die -Eigenschaft nicht mit der Anforderung angegeben wird, wird sie für das Blob gelöscht, wenn die Anforderung erfolgreich ist.
`x-ms-blob-content-type`	Optional. Legt den Inhaltstyp des BLOB fest. Wenn sie angegeben ist, wird diese Eigenschaft mit dem Blob gespeichert und mit einer Leseanforderung zurückgegeben. Wenn der Inhaltstyp nicht angegeben wird, wird er auf den Standardtyp festgelegt, nämlich `application/octet-stream`.
`x-ms-blob-content-encoding`	Optional. Legt die Inhaltscodierung des BLOB fest. Wenn sie angegeben ist, wird diese Eigenschaft mit dem Blob gespeichert und mit einer Leseanforderung zurückgegeben. Wenn die -Eigenschaft nicht mit der Anforderung angegeben wird, wird sie für das Blob gelöscht, wenn die Anforderung erfolgreich ist.
`x-ms-blob-content-language`	Optional. Legt die Inhaltssprache des Blobs fest. Wenn sie angegeben ist, wird diese Eigenschaft mit dem Blob gespeichert und mit einer Leseanforderung zurückgegeben. Wenn die -Eigenschaft nicht mit der Anforderung angegeben wird, wird sie für das Blob gelöscht, wenn die Anforderung erfolgreich ist.
`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 ü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 wird, wird sie für das Blob gelöscht, wenn die Anforderung erfolgreich ist.
`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#-Bezeichner entsprechen.
`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, die committet werden. Dieser Header wird ab Version 2019-02-02 unterstützt.
`x-ms-encryption-context`	Optional. Der Standardwert ist "Leer". Wenn der Wert festgelegt ist, werden Blobsystemmetadaten festgelegt. Maximale Länge: 1024. Gültig nur, wenn hierarchischer Namespace für das Konto aktiviert ist. Dieser Header wird in Versionen 2021-08-06 und höher unterstützt.
`x-ms-tags`	Optional. Legt die angegebenen abfragezeichenfolgencodierten Tags für das Blob fest. Weitere Informationen finden Sie im Abschnitt Hinweise . 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, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der in den Analyseprotokollen aufgezeichnet wird, wenn die Speicheranalyseprotokollierung konfiguriert ist. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt.
`x-ms-blob-content-disposition`	Optional. Legt den `Content-Disposition`-Header des BLOBs fest. Verfügbar für Version 2013-08-15 und höher. Das `Content-Disposition` Headerfeld vermittelt zusätzliche Informationen zur Verarbeitung der Antwortnutzlast und kann zum Anfügen zusätzlicher Metadaten verwendet werden. Wenn sie beispielsweise auf `attachment`festgelegt ist, gibt dieser Header an, dass der Benutzer-Agent die Antwort nicht anzeigen soll, sondern stattdessen ein Dialogfeld Speichern unter anzeigen soll. Die Antwort aus den Vorgängen Get Blob und Get Blob Properties enthält den Inhaltsdispositionsheader.
`x-ms-access-tier`	Optional. Version 2018-11-09 und höher. Gibt die Ebene an, die für ein Blob festgelegt werden soll. Für Blockblobs wird dieser Header nur für Blob storage- oder v2-Konten mit allgemeiner Verwendung mit Version 2018-11-09 und höher unterstützt. Gültige Werte für Blockblobebenen sind `Hot`, `Cool`, `Cold`und `Archive`. Hinweis: `Cold` Die Ebene wird ab Version 2021-12-02 unterstützt. Ausführliche Informationen zum Blockblobtiering finden Sie unter Speicherebenen heiß, kalt und archivieren.
`x-ms-immutability-policy-until-date`	Version 2020-06-12 und höher. Gibt das Aufbewahrungsdatum an, das für das Blob festgelegt werden soll. Dies ist das Datum, bis zu dem das Blob vor Änderungen oder Löschungen geschützt werden kann. Folgt RFC1123 Format.
`x-ms-immutability-policy-mode`	Version 2020-06-12 und höher. Gibt den Unveränderlichkeitsrichtlinienmodus an, der für das Blob festgelegt werden soll. Gültige Werte sind `unlocked` und `locked`. Der `unlocked` Wert gibt an, dass Benutzer die Richtlinie ändern können, indem sie die Aufbewahrung bis zum Datum erhöhen oder verringern. Der `locked` Wert gibt an, dass diese Aktionen verboten sind.
`x-ms-legal-hold`	Version 2020-06-12 und höher. Gibt den gesetzlichen Halteraum an, der für das Blob festgelegt werden soll. Die gültigen Werte sind `true` und `false`.
`x-ms-expiry-option`	Optional. Version 2023-08-03 und höher. Gibt die Ablaufdatumsoption für die Anforderung an, siehe ExpiryOption. Dieser Header ist für Konten gültig, deren hierarchischer Namespace aktiviert ist.
`x-ms-expiry-time`	Optional. Version 2023-08-03 und höher. Gibt den Zeitpunkt an, zu dem das Blob auf Ablauf festgelegt ist. Das Format für das Ablaufdatum variiert je nach `x-ms-expiry-option`. Weitere Informationen finden Sie unter ExpiryOption. Dieser Header ist für Konten gültig, deren hierarchischer Namespace aktiviert ist. Das `expiryTime` bereits in einem Blob vorhandene wird nicht gelöscht, wenn die Anforderung keinen neuen Wert enthält. `expiryTime`

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 Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Ab Version 2019-02-02 können Sie die folgenden Header für die Anforderung angeben, ein Blob mit einem vom Kunden bereitgestellten Schlüssel zu verschlüsseln. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und der entsprechenden Gruppe 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 die Blockliste angeben, die Blob Storage auf 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 erneut zu laden. Nachdem Sie den oder die geänderten Blöcke hochgeladen haben, können Sie eine neue Version des Blobs committen, indem Sie die neuen Blöcke zusammen mit den vorhandenen Blöcken committen, die Sie beibehalten möchten.

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. Um anzugeben, welcher Ansatz verwendet werden soll, geben Sie die Block-ID innerhalb des entsprechenden XML-Elements im Anforderungstext wie folgt an:

Geben Sie die Block-ID innerhalb des Committed Elements an, um anzugeben, dass Blob Storage nur die Commitliste nach dem benannten Block durchsuchen soll. Wenn der Block nicht in der Liste der zugesagten Blöcke gefunden wird, wird er nicht als Teil des Blobs geschrieben, und Blob Storage gibt status Code 400 (Ungültige Anforderung) zurück.
Geben Sie die Block-ID innerhalb des Uncommitted -Elements an, um anzugeben, dass Blob Storage nur die nicht festgelegte Blockliste nach dem benannten Block durchsuchen soll. Wenn der Block nicht in der Nicht-Blockliste gefunden wird, wird er nicht als Teil des Blobs geschrieben, und Blob Storage gibt status Code 400 (Ungültige Anforderung) zurück.
Geben Sie die Block-ID innerhalb des Latest -Elements an, um anzugeben, dass Blob Storage zuerst die nicht festgelegte Blockliste 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. Wenn der Block nicht in der Liste ohne Verpflichtung gefunden wird, sollte der Dienst die Liste der commitierten Blöcke nach dem benannten Block durchsuchen und diesen Block in das Blob schreiben, wenn er gefunden wird.

Der Anforderungstext für diese Version von Put Block List verwendet das folgende 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

Put Block ListAngenommen, Sie haben drei Blöcke hochgeladen, die Sie jetzt committen möchten. 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>

Als Nächstes gehen wir davon aus, 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 er wird bis zum Put Block ListAufruf von in der Blockliste ohne Sperre angezeigt.
Eine aktualisierte Version des Blocks mit der ID AZAAAA==. Dieser Block muss zuerst mit einem Aufruf von Put Block hochgeladen werden, und er wird bis zum Put Block ListAufruf von in der Blockliste ohne Sperre angezeigt.
Entfernen des Blocks mit der ID AAAAAA==. Da dieser Block nicht im nächsten Aufruf von Put Block Listenthalten 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  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
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.

Weitere Informationen zu status Codes 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 Darstellen von Datums-/Uhrzeitwerten in Headern. 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`	Wird zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Dieser Header bezieht sich auf den Inhalt der Anforderung (in diesem Fall die Liste der Blöcke und nicht den Inhalt des Blobs selbst). Ab Version 2019-02-02 wird dieser Header nur zurückgegeben, wenn die Anforderung über diesen Header verfügt.
`x-ms-content-crc64`	Ab Version 2019-02-02 wird dieser Header zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Dieser Header bezieht sich auf den Inhalt der Anforderung (in diesem Fall die Liste der Blöcke und nicht den Inhalt des Blobs selbst). Dieser Header wird zurückgegeben, wenn `Content-md5` der Header in der Anforderung nicht vorhanden ist.
`x-ms-request-id`	Identifiziert die durchgeführte Anforderung eindeutig, und Sie können sie zur Problembehandlung für die Anforderung verwenden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
`x-ms-version`	Die Version von Blob Storage, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher ausgeführt werden.
`Date`	Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der angibt, wann 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 mit dem angegebenen Algorithmus erfolgreich verschlüsselt wurde. Andernfalls wird der Wert auf `false` festgelegt.
`x-ms-encryption-key-sha256`	Version 2019-02-02 und höher. 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 mithilfe des bereitgestellten Schlüssels erfolgreich verschlüsselt wurde.
`x-ms-encryption-scope`	Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des Verschlüsselungsbereichs erfolgreich verschlüsselt wurde.
`x-ms-version-id: <DateTime>`	Version 2019-12-12 und höher. Gibt einen undurchsichtigen `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`	Kann zur Problembehandlung von Anforderungen und deren entsprechenden Antworten verwendet werden. 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.

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>

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Put Block List Vorgang wie unten beschrieben autorisieren.

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

Wichtig

Microsoft empfiehlt die Verwendung von Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam genutzten Schlüsseln eine höhere Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen für Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

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

Berechtigungen

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 Block List Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion enthält:

Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Integrierte Rolle mit den geringsten Berechtigungen:Mitwirkender an Storage-Blobdaten

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

Eine Shared Access Signature (SAS) bietet sicheren delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS haben Sie eine präzise Kontrolle darüber, wie ein Client auf Daten zugreifen kann. Sie können angeben, auf welche Ressource der Client zugreifen darf, über welche Berechtigungen er für diese Ressourcen verfügt und wie lange die SAS gültig ist.

Der Put Block List Vorgang unterstützt drei Arten von Shared Access Signatures: Sas für die Benutzerdelegierung, Dienst-SAS und Konto-SAS.

Als bewährte Sicherheitsmethode wird empfohlen, Microsoft Entra Anmeldeinformationen anstelle des Speicherkontoschlüssels zu verwenden, der leichter kompromittiert werden kann. Wenn Ihr Anwendungsentwurf Shared Access Signatures erfordert, verwenden Sie nach Möglichkeit Microsoft Entra Anmeldeinformationen, um eine SAS für die Benutzerdelegierung zu erstellen.

Wenn der Zugriff mit gemeinsam genutzten Schlüsseln für das Speicherkonto nicht zulässig ist, ist ein Sas-Diensttoken oder ein Konto-SAS-Token bei einer Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Grundlegendes dazu, wie sich die Aufhebung der Verwendung gemeinsam genutzter Schlüssel auf SAS-Token auswirkt.

SAS für die Benutzerdelegierung

Eine SAS für die Benutzerdelegierung wird mit Microsoft Entra Anmeldeinformationen und auch durch die für die SAS angegebenen Berechtigungen geschützt.

Für das Aufrufen des Put Block List Vorgangs mit einem SAS-Token, das an einen Container oder eine Blobressource delegiert wird, ist die Schreibberechtigung (w) als Teil des SAS-Tokens für die Benutzerdelegierung erforderlich.

Weitere Informationen zur SAS für die Benutzerdelegierung finden Sie unter Create einer SAS für die Benutzerdelegierung.

Dienst-SAS

Eine Dienst-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Dienst-SAS delegiert den Zugriff auf eine Ressource in einem einzelnen Azure Storage-Dienst, z. B. BlobSpeicher.

Weitere Informationen zur Dienst-SAS finden Sie unter Create einer Dienst-SAS.

Konto-SAS

Eine Konto-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Konto-SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren der Speicherdienste. Alle Vorgänge, die über eine Dienst-SAS oder eine SAS für die Benutzerdelegierung verfügbar sind, sind auch über eine Konto-SAS verfügbar.

In der folgenden Tabelle sind der Typ der signierten Ressource und die signierten Berechtigungen angegeben, die beim Delegieren des Zugriffs angegeben werden sollen:

Vorgang	Signierter Dienst	Signierter Ressourcentyp	Signierte Berechtigung
Put Block List	Blob (b)	Objekt (o)	Schreiben (w)

Weitere Informationen zur Konto-SAS finden Sie unter Create einer Konto-SAS.

Der Put Block List Vorgang unterstützt die Autorisierung mit gemeinsam verwendeten Schlüsseln. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist.

Microsoft empfiehlt, die Autorisierung mit gemeinsam genutzten Schlüsseln für das Speicherkonto nach Möglichkeit zu deaktivieren. Weitere Informationen finden Sie unter Verhindern der Autorisierung mit gemeinsam verwendetem Schlüssel.

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 wird, stellt sie den Bytebereich an jedem dieser Speicherorte in der Blockliste für das endgültige committete Blob 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 Listkönnen Sie ein vorhandenes Blob ändern, indem Sie einzelne Blöcke einfügen, aktualisieren oder löschen, ohne das gesamte Blob erneut hochladen zu müssen. 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 ohne Commit und den Rest aus der Commit-Blockliste angeben, 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 committeten Blöcke, aber nicht in der Blockliste ohne Commit vorhanden ist, Put Block List wird der Block aus der Liste der committeten Blöcke committent.

Jeder Block in einem Blockblob kann eine andere Größe aufweisen. Ein Blockblob kann maximal 50.000 committete Blöcke enthalten. Die maximale Anzahl von Blöcken ohne Commit, die einem Blob zugeordnet sein können, beträgt 100.000.

In der folgenden Tabelle werden die maximal zulässigen Block- und Blobgrößen nach Dienstversion beschrieben:

Dienstversion	Maximale Blockgröße (über `Put Block`)	Maximale Blobgröße (über `Put Block List`)	Maximale Blobgröße über einen einzelnen Schreibvorgang (über `Put Blob`)
Ab Version 2019-12-12	4.000 Mebibyte (MiB)	Ca. 190,7 Tebibyte (TiB) (4.000 MiB × 50.000 Blöcke)	5.000 MiB
Versionen 2016-05-31 bis 2019-07-07	100 MiB	Ungefähr 4,75 TiB (100 MiB × 50.000 Blöcke)	256 MiB
Versionen vor 2016-05-31	4 MiB	Ungefähr 195 GiB (4 MiB × 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 nicht freigegebenen Blöcke werden mit Müll gesammelt, wenn innerhalb einer Woche nach dem letzten erfolgreichen Put Block Vorgang keine erfolgreichen Aufrufe Put Block für oder Put Block List für das Blob ausgeführt werden. Wenn Put Blob für das Blob aufgerufen wird, werden alle nicht freigegebenen Blöcke mit Müll gesammelt.

Wenn Tags im x-ms-tags Header bereitgestellt werden, müssen sie abfragezeichenfolgencodiert sein. Tagschlüssel und -werte müssen den Benennungs- und Längenanforderungen entsprechen, wie in Set Blob Tagsangegeben. Darüber hinaus kann der x-ms-tags 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 eine gültige Lease-ID für die Anforderung zum Commit der Blockliste angeben. Wenn der Client entweder keine Lease-ID oder eine ungültige Lease-ID angibt, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Wenn der Client eine Lease-ID angibt, das Blob jedoch nicht über eine aktive Lease verfügt, gibt Blob Storage auch status Code 412 (Vorbedingung fehlgeschlagen) zurück. Wenn der Client eine Lease-ID für ein Blob angibt, das noch nicht vorhanden ist, gibt Blob Storage status Code 412 (Vorbedingungsfehler) für Anforderungen zurück, die für Die Version 2013-08-15 oder höher gestellt wurden. Für frühere Versionen gibt Blob Storage status Code 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).

Das Überschreiben eines archivierten Blobs schlägt fehl, und das Überschreiben eines hot oder cool Blobs erbt die Ebene vom alten Blob, wenn der Header x-ms-access-tier nicht bereitgestellt wird.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Put Block List Anforderungen basierend auf dem Speicherkontotyp:

Vorgang	Speicherkontotyp	Abrechnungskategorie
Put Block List	Premium, Blockblob Standard „Allgemein v2“ Standard „Allgemein v1“	Schreibvorgänge

Weitere Informationen zu Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.

Weitere Informationen

Grundlegendes zu Blockblobs, Anfügeblobs und Seitenblobs
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blobdienstfehlercodes
Festlegen von Timeouts für Blobdienstvorgänge

Freigeben über