Blobversiegelung anfügen
Der Zweck des Append Blob Seal
Vorgangs besteht darin, Benutzern und Anwendungen das Versiegeln von Anfügeblobs zu ermöglichen und sie als schreibgeschützt zu markieren. In diesem Dokument werden die vorgeschlagenen REST-API-Spezifikationen für dieses Feature beschrieben.
Anforderung
Sie können die Append Blob Seal
Anforderung wie folgt erstellen. HTTPS wird empfohlen. Ersetzen Sie myaccount
durch den Namen Ihres Speicherkontos.
PUT-Methodenanforderungs-URI | HTTP-Version |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal |
HTTP/1.1 |
Header
Append Blob Seal
gibt allgemeine API-Header zurück ( ETag
/LMT
Zeitpunkt der letzten Änderung), x-ms-request-id
, x-ms-version
, content-length
und .Date
Append Blob Seal
ändert nicht .ETag
/LMT
Antwortheader | Wert | Beschreibung |
---|---|---|
x-ms-blob-sealed |
TRUE/FALSE | Optional. Der Standardwert ist gleich „False“. Wenn das Blob versiegelt ist, ist dieser Header in der Antwort enthalten, wenn Sie eigenschaften eines Blobs versiegeln und abrufen. Dieser Header sollte in GetBlob , GetBlobProperties , AppendBlobSeal und ListBlobs für Anfügeblobs angezeigt werden. |
Abfrageparameter
Keine zusätzlichen URI-Parameter.
Anforderungstext
Keine.
Antwort
Die Antwort enthält einen HTTP-status Code und eine Liste von Antwortheadern.
Statuscode
Möglicherweise erhalten Sie einen der folgenden status Codes:
200 (Erfolg): Das Blob ist versiegelt. Der Aufruf ist idempotent und erfolgreich, wenn das Blob bereits versiegelt ist.
409 (InvalidBlobType): Der Dienst gibt diesen status Code zurück, wenn der Aufruf in einem vorhandenen Seitenblob oder Blockblob erfolgt.
404 (BlobNotFound): Der Dienst gibt diesen status Code zurück, wenn der Aufruf in einem nicht vorhandenen Blob erfolgt.
Authorization
Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Append Blob Seal
Vorgang wie unten beschrieben autorisieren.
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
Unten sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, eine Gruppe oder einen Dienstprinzipal erforderlich ist, um den Append Blob Seal
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.
Hinweise
Wenn ein Anfügeblob über eine Lease verfügt, benötigen Sie eine Lease-ID, um das Blob zu versiegeln.
Nachdem Sie ein Blob versiegelt haben, können Sie weiterhin Eigenschaften, Blobindextags und Metadaten aktualisieren. Das vorläufige Löschen eines versiegelten Blobs behält den versiegelten Zustand bei. Sie können versiegelte Blobs überschreiben.
Wenn Sie eine Momentaufnahme eines versiegelten Blobs verwenden, enthält die Momentaufnahme das versiegelte Flag. Für vorhandene Momentaufnahmen in der neuen Version gibt Microsoft die -Eigenschaft zurück.
Wenn Sie ein versiegeltes Blob kopieren, wird das versiegelte Flag standardmäßig weitergegeben. Ein Header wird verfügbar gemacht, mit dem das Flag überschrieben werden kann.
Der Antwort wird ein neues XML-Element mit dem ListBlob
Namen Sealed
hinzugefügt. Der Wert kann entweder true
oder false
sein.
Wenn Sie für ein Blob aufrufen AppendBlock
, das bereits versiegelt ist, gibt der Dienst die in der folgenden Tabelle gezeigte Fehlermeldung zurück. Dies gilt für ältere Versionen der API.
Fehlercode | HTTP-Statuscode | Meldung für den Benutzer |
---|---|---|
BlobIsSealed | Konflikt (409) | Das angegebene Blob ist versiegelt, und sein Inhalt kann nur geändert werden, wenn das Blob nach einem Löschvorgang neu erstellt wird. |
Wenn Sie ein Anfügeblob aufrufenAppend Blob Seal
, das bereits versiegelt wurde, wird einfach der status Code 200 (Erfolg) angezeigt.
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 Abrechnung des Kontos aus. Beispielsweise werden Lesetransaktionen einer anderen Abrechnungskategorie zugeordnet als Schreibtransaktionen. Die folgende Tabelle zeigt die Abrechnungskategorie für Append Blob Seal
Anforderungen basierend auf dem Speicherkontotyp:
Vorgang | Speicherkontotyp | Abrechnungskategorie |
---|---|---|
Blobversiegelung anfügen | Premium, Blockblob Standard „Allgemein v2“ Standard „Allgemein v1“ |
Schreibvorgänge |
Informationen zu den Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.