Get Blob Properties

Artikel
03/16/2023

Mit dem Get Blob Properties-Vorgang werden alle benutzerdefinierten Metadaten, HTTP-Standardeigenschaften und Systemeigenschaften für das BLOB zurückgegeben. Der Inhalt des Blobs wird nicht zurückgegeben.

Anforderung

Sie können die Get Blob Properties Anforderung wie folgt erstellen. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos.

HEAD Methodenanforderungs-URI	HTTP-Version
`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>`	HTTP/1.1

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung an den emulierten Speicherdienst stellen, geben Sie den Emulatorhostnamen und Azure Blob Storage Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

HEAD Methodenanforderungs-URI	HTTP-Version
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azure-Speicheremulators für Entwicklung und Tests.

URI-Parameter

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

Parameter	BESCHREIBUNG
`snapshot`	Optional. Der parameter Momentaufnahme ist ein undurchsichtiger `DateTime` Wert, der, wenn er vorhanden ist, die abzurufende Blob-Momentaufnahme angibt. Weitere Informationen zum Arbeiten mit Blobmomentaufnahmen finden Sie unter Erstellen einer Momentaufnahme eines Blobs.
`versionid`	Optional. Version 2019-12-12 und höher. Der `versionid` Parameter ist ein undurchsichtiger `DateTime` Wert, der, wenn er vorhanden ist, die Version des abzurufenden Blobs angibt.
`timeout`	Optional. Der `timeout`-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgä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. Optional für anonyme Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
`x-ms-lease-id: <ID>`	Optional. Wenn dieser Header angegeben ist, wird der `Get Blob Properties` Vorgang nur ausgeführt, wenn beide der folgenden Bedingungen erfüllt sind: – Die Lease des Blobs ist derzeit aktiv. – Die in der Anforderung angegebene Lease-ID entspricht der Lease-ID des Blobs. Wenn eine dieser Bedingungen nicht erfüllt ist, schlägt die Anforderung fehl, und der `Get Blob Properties` Vorgang schlägt mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.
`x-ms-upn`	Optional. Version 2020-06-12 und höher. Gültig für Konten mit aktiviertem hierarchischem Namespace. Wenn die in `x-ms-owner` zurückgegebenen Benutzeridentitätswerte true sind, werden sie von Microsoft Entra Objekt-IDs in Benutzerprinzipalnamen transformiert. Wenn die Werte false sind, werden sie als Microsoft Entra Objekt-IDs zurückgegeben. Der Standardwert ist false. Beachten Sie, dass Gruppen- und Anwendungsobjekt-IDs nicht übersetzt werden, da sie keine eindeutigen Anzeigenamen haben.
`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 Protokollierung der Speicheranalyse aktiviert ist. Es wird dringend empfohlen, diesen Header zu verwenden, wenn Sie clientseitige Aktivitäten mit Anforderungen korrelieren, die vom Server empfangen werden. Weitere Informationen finden Sie unter Informationen zur Azure-Storage Analytics-Protokollierung.

Dieser Vorgang unterstützt die Verwendung von bedingten Headern zum Zurückgeben von BLOB-Eigenschaften und -Metadaten nur dann, wenn eine angegebene 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, um ein Blob zu lesen, das mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt ist. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und dem entsprechenden Satz von Headern) ist optional. Wenn ein Blob zuvor mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt wurde, müssen Sie diese Header in die Anforderung einschließen, damit der Lesevorgang erfolgreich abgeschlossen werden kann.

Anforderungsheader	BESCHREIBUNG
`x-ms-encryption-key`	Erforderlich. Der Base64-codierte AES-256-Verschlüsselungsschlüssel.
`x-ms-encryption-key-sha256`	Optional. 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

Keine.

Antwort

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

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

Weitere Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

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

Antwortheader	BESCHREIBUNG
`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.
`x-ms-creation-time`	Version 2017-11-09 und höher. Das Datum/die Uhrzeit der Erstellung des Blobs. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Headern.
`x-ms-meta-name:value`	Ein Satz von Name-Wert-Paaren, die den benutzerdefinierten Metadaten entsprechen, die diesem Blob zugeordnet sind.
`x-ms-tag-count`	Version 2019-12-12 und höher. Wenn das Blob über Tags verfügt, gibt die Anzahl der tags zurück, die im Blob gespeichert sind. Dieser Header wird nicht zurückgegeben, wenn im Blob keine Tags vorhanden sind.
`x-ms-blob-type:<BlockBlob\\|PageBlob\\|AppendBlob>`	Der BLOB-Typ.
`x-ms-copy-completion-time:<datetime>`	Version 2012-02-12 und höher. Die Abschlusszeit des letzten versuchten `Copy Blob`-Vorgangs, bei dem dieses BLOB das Ziel-BLOB war. Dieser Wert kann die Zeit eines abgeschlossenen, abgebrochenen oder fehlgeschlagenen Kopierversuchs angeben. Dieser Header wird nicht angezeigt, wenn eine Kopie aussteht, wenn dieses Blob noch nie das Ziel in einem `Copy Blob` Vorgang war oder wenn dieses Blob nach einem abgeschlossenen `Copy Blob` Vorgang geändert wurde, der , `Put Blob`oder `Put Block List`verwendet`Set Blob Properties`.
`x-ms-copy-status-description: <error string>`	Version 2012-02-12 und höher. Wird nur angezeigt, wenn `x-ms-copy-status` oder `pending`ist`failed`. Beschreibt die Ursache eines schwerwiegenden oder nicht tödlichen Kopiervorgangsfehlers. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem `Copy Blob` Vorgang war oder wenn dieses Blob nach einem abgeschlossenen `Copy Blob` Vorgang geändert wurde, der , `Put Blob`oder `Put Block List`verwendet`Set Blob Properties`.
`x-ms-copy-id: <id>`	Version 2012-02-12 und höher. Der Zeichenfolgenbezeichner für den letzten versuchten `Copy Blob` Vorgang, bei dem dieses Blob das Zielblob war. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem `Copy Blob` Vorgang war oder wenn dieses Blob nach einem abgeschlossenen `Copy Blob` Vorgang geändert wurde, der , `Put Blob`oder `Put Block List`verwendet`Set Blob Properties`.
`x-ms-copy-progress: <bytes copied/bytes total>`	Version 2012-02-12 und höher. Enthält die Anzahl der kopierten Bytes und die Gesamtanzahl der Bytes in der Quelle im letzten versuchten `Copy Blob` Vorgang, wobei dieses Blob das Zielblob war. Kann von 0 bis kopierten `Content-Length` Bytes angezeigt werden. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem `Copy Blob` Vorgang war oder wenn dieses Blob nach einem abgeschlossenen `Copy Blob` Vorgang geändert wurde, der , `Put Blob`oder `Put Block List`verwendet`Set Blob Properties`.
`x-ms-copy-source: url`	Version 2012-02-12 und höher. Eine URL mit einer Länge von bis zu 2 KiB, die das Quellblob angibt, das beim letzten versuchten `Copy Blob` Vorgang verwendet wurde, wobei dieses Blob das Zielblob war. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem `Copy Blob` Vorgang war oder wenn dieses Blob nach einem abgeschlossenen `Copy Blob` Vorgang geändert wurde, der , `Put Blob`oder `Put Block List`verwendet`Set Blob Properties`.
`x-ms-copy-status: <pending \\| success \\| aborted \\| failed>`	Version 2012-02-12 und höher. Der Durch x-ms-copy-id identifizierte Zustand des Kopiervorgangs mit den folgenden Werten: - `success`: Der Kopiervorgang wurde erfolgreich abgeschlossen. - `pending`: Der Kopiervorgang wird ausgeführt. Überprüfen Sie `x-ms-copy-status-description`. Zeitweilige, nicht schwerwiegende Fehler behindern den Kopiervorgang, verursachen jedoch keinen Fehler. - `aborted`: Die Kopie wurde durch `Abort Copy Blob`beendet. - `failed`: Fehler beim Kopieren. Fehlerdetails finden Sie in `x-ms-copy-status-description`. Dieser Header wird nicht angezeigt, wenn dieses Blob noch nie das Ziel in einem `Copy Blob` Vorgang war oder wenn dieses Blob nach einem abgeschlossenen `Copy Blob` Vorgang geändert wurde, der , `Put Blob`oder `Put Block List`verwendet`Set Blob Properties`.
`x-ms-incremental-copy: true`	Version 2016-05-31 und höher. Enthalten, wenn es sich bei dem Blob um ein inkrementelles Kopierblob handelt.
`x-ms-copy-destination-snapshot:<datetime>`	Version 2016-05-31 und höher. Enthalten, wenn das Blob ein inkrementelles Kopierblob oder ein inkrementelles Kopierblob Momentaufnahme ist, falls `x-ms-copy-status` erfolgreich. Momentaufnahmezeit der letzten erfolgreichen inkrementellen Kopie Momentaufnahme für dieses Blob.
`x-ms-lease-duration: <infinite \\| fixed>`	Gibt für ein geleastes BLOB an, ob die Lease von unbegrenzter oder fester Dauer ist. Enthalten für Anforderungen, die Version 2012-02-12 und höher verwenden.
`x-ms-lease-state: <available \\| leased \\| expired \\| breaking \\| broken>`	Der Leasestatus des Blobs. Enthalten für Anforderungen, die Version 2012-02-12 und höher verwenden.
`x-ms-lease-status:<locked\\| unlocked>`	Der Leasestatus des BLOB.
`Content-Length`	Die Größe des Blobs in Byte. Bei einem Seitenblob gibt dieser Header den Wert des Headers zurück, der `x-ms-blob-content-length` mit dem Blob gespeichert ist.
`Content-Type`	Der inhaltstyp, der für das Blob angegeben wird. Wenn kein Inhaltstyp angegeben wird, ist `application/octet-stream`der Standardinhaltstyp .
`Etag`	Das ETag enthält einen Wert, den Sie verwenden können, um Vorgänge bedingt auszuführen. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.
`Content-MD5`	Wenn der `Content-MD5`-Header für das BLOB festgelegt wurde, wird dieser Antwortheader zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Legt in Version 2012-02-12 und höher den MD5-Wert eines Blockblobs fest, `Put Blob` auch wenn die `Put Blob` Anforderung keinen MD5-Header enthält.
`Content-Encoding`	Wenn zuvor der `Content-Encoding`-Anforderungsheader für das BLOB festgelegt wurde, wird dieser Wert in diesem Header zurückgegeben.
`Content-Language`	Wenn zuvor der `Content-Language`-Anforderungsheader für das BLOB festgelegt wurde, wird dieser Wert in diesem Header zurückgegeben.
`Content-Disposition`	Wenn zuvor der `Content-Disposition`-Anforderungsheader für das BLOB festgelegt wurde, wird der Wert in diesem Header für Anforderungen zurückgegeben, die für Version 2013-08-15 und höher erfolgen. Das Feld mit dem `Content-Disposition`-Antwortheader 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 Header beispielsweise auf festgelegt ist, gibt dies an `attachment`, dass der Benutzer-Agent die Antwort nicht anzeigen soll, sondern stattdessen ein Dialogfeld Speichern unter anzeigen soll.
`Cache-Control`	Wenn zuvor der `Cache-Control`-Anforderungsheader für das BLOB festgelegt wurde, wird dieser Wert in diesem Header zurückgegeben.
`x-ms-blob-sequence-number`	Die aktuelle Sequenznummer für ein Seitenblob. Dieser Header wird nicht für Blockblobs oder Anfügeblobs zurückgegeben. Dieser Header wird für Blockblobs nicht zurückgegeben.
`x-ms-request-id`	Dieser Header identifiziert eindeutig die Anforderung, die gestellt wurde, und Sie können ihn verwenden, um die Problembehandlung für die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
`x-ms-version`	Gibt die Blob Storage-Version an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die ab Version 2009-09-19 gestellt werden. Dieser Header wird auch für anonyme Anforderungen ohne angegebene Version zurückgegeben, wenn der Container mit Blob Storage-Version 2009-09-19 für den öffentlichen Zugriff markiert wurde.
`Date`	Ein vom Dienst generierter UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
`Accept-Ranges: bytes`	Gibt an, dass der Dienst Anforderungen für teilweisen BLOB-Inhalt unterstützt. Enthalten für Anforderungen, die mit Version 2013-08-15 und höher erstellt wurden.
`x-ms-blob-committed-block-count`	Die Anzahl der committeten Blöcke, die im Blob vorhanden sind. Dieser Header wird nur für Anfügeblobs zurückgegeben.
`x-ms-server-encrypted: true/false`	Version 2015-12-11 und höher. Der Wert dieses Headers wird auf `true` festgelegt, wenn die Blobdaten und Anwendungsmetadaten mit dem angegebenen Algorithmus vollständig verschlüsselt werden. Andernfalls wird der Wert auf `false` festgelegt (wenn das Blob unverschlüsselt ist oder wenn nur Teile der Blob-/Anwendungsmetadaten verschlüsselt sind).
`x-ms-encryption-key-sha256`	Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn das Blob mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt ist.
`x-ms-encryption-context`	Version 2021-08-06 und höher. Wenn der Wert der Verschlüsselungskontexteigenschaft festgelegt ist, wird der Festgelegtwert zurückgegeben. Gültig nur, wenn hierarchischer Namespace für das Konto aktiviert ist.
`x-ms-encryption-scope`	Version 2019-02-02 und höher. Dieser Header wird zurückgegeben, wenn das Blob mit einem Verschlüsselungsbereich verschlüsselt ist.
`x-ms-access-tier`	Version 2017-04-17 und höher. Die Ebene des Seitenblobs auf einem Storage Premium Konto oder Ebene eines Blockblobs in einem Blob Storage- oder v2-Konto für allgemeine Zwecke. Eine Liste der zulässigen Premium-Seitenblobebenen finden Sie unter Hochleistungs-Storage Premium und verwaltete Datenträger für VMs. Für Blob Storage- oder Allgemeine v2-Konten sind `Hot`gültige Werte , `Cool`, `Cold`und `Archive`. Hinweis:`Cold` die Ebene wird ab Version 2021-12-02 unterstützt. Ausführliche Informationen zum Block-Blob-Level-Tiering für Standardblobkonten finden Sie unter Speicherebene "Heiß", "Kalt" und "Archiv".
`x-ms-access-tier-inferred: true`	Version 2017-04-17 und höher. Nur für Seitenblobs in einem Storage Premium Konto. Wenn die Zugriffsebene nicht explizit für das Blob festgelegt ist, wird die Ebene basierend auf ihrer Inhaltslänge abgeleitet, und dieser Header wird mit dem Wert zurückgegeben `true`. Wenn für Blockblobs in Blob Storage oder einem Konto für allgemeine Zwecke v2 nicht die Zugriffsebene festgelegt ist, können Sie die Ebene aus den Eigenschaften des Speicherkontos ableiten. Dieser Header wird nur festgelegt, wenn die Blockblobebene abgeleitet wird.
`x-ms-archive-status`	Version 2017-04-17 und höher. Für Blob Storage- oder v2-Konten mit allgemeinem Zweck sind `rehydrate-pending-to-hot`gültige Werte , `rehydrate-pending-to-cool`und `rehydrate-pending-to-cold`. Wenn das Blob rehydriert wird und unvollständig ist, wird dieser Header zurückgegeben, was beide angibt, dass das Rehydrat aussteht und die Zielebene anzeigt. Ausführliche Informationen zum Blocktiering auf Blobebene für Standardblobkonten finden Sie unter Speicherebene heiß, kalt und archivieren.
`x-ms-access-tier-change-time`	Version 2017-04-17 und höher. Gibt den Zeitpunkt an, zu dem die Ebene zuletzt für das Objekt geändert wurde. Dieser Header wird nur zurückgegeben, wenn jemals eine Ebene für Blockblob festgelegt wurde. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Headern. Weitere Informationen zum Blocktiering auf Blobebene für Standardblobkonten finden Sie unter Speicherebene heiß, kalt und archivieren.
`x-ms-client-request-id`	Kann verwendet werden, um Anforderungen und ihre entsprechenden Antworten zu behandeln. Der Wert dieses Headers entspricht dem Wert des `x-ms-client-request-id` Headers, wenn er in der Anforderung vorhanden ist, und der Wert höchstens 1.024 sichtbare ASCII-Zeichen ist. Wenn der `x-ms-client-request-id` Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.
`x-ms-rehydrate-priority`	Version 2019-12-12 und höher. Wenn sich ein Objekt im Zustand rehydrate pending befindet, wird dieser Header mit der Priorität rehydrate zurückgegeben. Gültige Werte sind `High`/`Standard`. Ausführliche Informationen zum Block-Blob-Level-Tiering für Standardblobkonten finden Sie unter Speicherebene "Heiß", "Kalt" und "Archiv".
`x-ms-or-{policy-id}_{rule-id}`	Version 2019-12-12 und höher, nur für Blockblobs zurückgegeben. `policy-id` ist ein GUID-Wert, der den Bezeichner einer Objektreplikationsrichtlinie für das Speicherkonto darstellt. `rule-id` ist ein GUID-Wert, der den Bezeichner einer Richtlinienregel im Blobcontainer darstellt. Wenn das Konto aktiviert ist`ObjectReplication`, stellt der Wert dieses Headers die Replikation status des Blobs mit den angegebenen Richtlinien- und Regelbezeichnern dar, entweder `complete` oder `failed`.
`x-ms-or-policy-id`	Version 2019-12-12 und höher, nur für Blockblobs zurückgegeben. Wenn das Konto aktiviert ist `ObjectReplication`, stellt der Wert dieses Headers die Richtlinie dar, die die Replikation steuert.
`x-ms-last-access-time`	Version 2020-02-10 und höher. Gibt den letzten Zeitpunkt an, zu dem auf die Daten des Blobs zugegriffen wurde, basierend auf der Richtlinie zur Nachverfolgung der letzten Zugriffszeit des Speicherkontos. Der Header wird nicht zurückgegeben, wenn das Speicherkonto nicht über eine Richtlinie zur Nachverfolgung der letzten Zugriffszeit verfügt oder die Richtlinie deaktiviert ist. Informationen zum Festlegen der Richtlinie für die Nachverfolgung der letzten Zugriffszeit des Speicherkontos finden Sie unter Blob Storage-API.
`x-ms-blob-sealed`	Version 2019-12-12 und höher, nur für Anfügeblobs zurückgegeben. Wenn das Anfügeblob versiegelt wurde, ist der Wert true. Weitere Informationen finden Sie unter Anfügen eines Blobsiegels.
`x-ms-immutability-policy-until-date`	Version 2020-06-12 und höher. Gibt das für das Blob festgelegte Datum "Aufbewahrung bis" an. Dies ist das Datum, bis zu dem das Blob vor Änderungen oder Löschungen geschützt werden kann. Wird nur zurückgegeben, wenn eine Unveränderlichkeitsrichtlinie für das Blob festgelegt ist. Der Wert dieses Headers ist RFC1123 Format.
`x-ms-immutability-policy-mode: unlocked/locked`	Version 2020-06-12 und höher. Der Unveränderlichkeitsrichtlinienmodus, der zurückgegeben wird, wenn eine Unveränderlichkeitsrichtlinie für das Blob festgelegt ist. Werte sind `unlocked`/`locked`. `unlocked` gibt an, dass der Benutzer die Richtlinie ändern kann, indem er die Aufbewahrung bis zum Datum erhöht oder verringert. `locked` gibt an, dass diese Aktionen verboten sind.
`x-ms-legal-hold: true/false`	Version 2020-06-12 und höher. Dieser Header wird nicht zurückgegeben, wenn für das Blob kein gesetzlicher Aufbewahrungsspeicher vorhanden ist. Der Wert dieses Headers wird auf true festgelegt, wenn das Blob einen legalen Halteraum enthält und sein Wert true ist. Andernfalls wird der Wert auf false festgelegt, wenn das Blob einen legalen Halteraum und seinen Wert false enthält.
`x-ms-owner`	Version 2020-06-12 und höher. Nur für Konten, für die ein hierarchischer Namespace aktiviert ist. Gibt den Besitzerbenutzer der Datei oder des Verzeichnisses zurück.
`x-ms-group`	Version 2020-06-12 und höher. Nur für Konten, für die ein hierarchischer Namespace aktiviert ist. Gibt die Besitzergruppe der Datei oder des Verzeichnisses zurück.
`x-ms-permissions`	Version 2020-06-12 und höher. Nur für Konten, für die ein hierarchischer Namespace aktiviert ist. Gibt die Berechtigungen zurück, die für Benutzer, Gruppe und andere für die Datei oder das Verzeichnis festgelegt sind. Jede einzelne Berechtigung hat das Format [r,w,x,-].{3}
`x-ms-resource-type`	Version 2020-10-02 und höher. Nur für Konten, für die ein hierarchischer Namespace aktiviert ist. Gibt den Ressourcentyp für den Pfad zurück, der entweder `file` oder sein `directory`kann.
`x-ms-expiry-time`	Version 2020-02-10 und höher. Nur für Konten, für die ein hierarchischer Namespace aktiviert ist. Gibt die Für das Blob festgelegte Ablaufzeit zurück. Wird nur für Dateien zurückgegeben, für die eine Ablaufzeit festgelegt ist.

Antworttext

Keine.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
x-ms-meta-Name: myblob.txt  
x-ms-meta-DateUploaded: <date>  
x-ms-blob-type: AppendBlob  
x-ms-lease-status: unlocked  
x-ms-lease-state: available  
Content-Length: 11  
Content-Type: text/plain; charset=UTF-8  
Date: <date>  
ETag: "0x8CAE97120C1FF22"  
Accept-Ranges: bytes  
x-ms-blob-committed–block-count: 1  
x-ms-version: 2015-02-21  
Last-Modified: <date>  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-copy-id: 36650d67-05c9-4a24-9a7d-a2213e53caf6  
x-ms-copy-source: <url>  
x-ms-copy-status: success  
x-ms-copy-progress: 11/11  
x-ms-copy-completion-time: <date>

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Get Blob Properties Vorgang wie unten beschrieben autorisieren.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen an Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung (Azure RBAC) von Azure 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 mit Microsoft Entra ID.

Berechtigungen

Im Folgenden sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, Eine Gruppe oder einen Dienstprinzipal erforderlich ist, um den Get Blob Properties 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/read
Integrierte Rolle mit den geringsten Berechtigungen:Speicherblobdatenleser

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

Eine SAS (Shared Access Signature) 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, welche Berechtigungen er für diese Ressourcen hat und wie lange die SAS gültig ist.

Der Get Blob Properties Vorgang unterstützt drei Arten von Shared Access Signaturen: Benutzerdelegierungs-SAS, 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 auf freigegebene Schlüssel für das Speicherkonto nicht zulässig ist, wird ein SAS-Diensttoken oder ein Konto-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Grundlegendes dazu, wie sich das Aufheben der Zuordnung von freigegebenem Schlüssel auf SAS-Token auswirkt.

SAS für die Benutzerdelegierung

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

Für das Aufrufen des Get Blob Properties Vorgangs mithilfe eines SAS-Tokens, das an einen Container oder eine Blobressource delegiert wurde, ist die Berechtigung Lesen (r) als Teil des SAS-Tokens der Benutzerdelegierung erforderlich.

Weitere Informationen zur Benutzerdelegierungs-SAS finden Sie unter Erstellen einer Benutzerdelegierungs-SAS.

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. Blob Storage.

Für das Aufrufen des Get Blob Properties Vorgangs mit einem SAS-Token, das an einen Container oder eine Blobressource delegiert wurde, ist die Leseberechtigung (r) als Teil des Dienst-SAS-Tokens erforderlich.

Weitere Informationen zur Dienst-SAS finden Sie unter Erstellen 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 signierte Ressourcentyp und die signierten Berechtigungen angegeben, die beim Delegieren des Zugriffs angegeben werden sollen:

Vorgang	Signierter Dienst	Signierter Ressourcentyp	Signierte Berechtigung
Get Blob Properties	Blob (b)	Objekt (o)	Lesen (r)

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

Der Get Blob Properties Vorgang unterstützt die Freigabeschlüsselautorisierung. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist.

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

Hinweise

Um zu ermitteln, ob ein Copy Blob Vorgang abgeschlossen wurde, überprüfen Sie zunächst, ob der x-ms-copy-id Headerwert der Kopier-ID entspricht, die vom ursprünglichen Aufruf Copy Blobvon bereitgestellt wurde. Eine Übereinstimmung stellt sicher, dass eine andere Anwendung die Kopie nicht abbricht und einen neuen Copy Blob Vorgang startet. Suchen Sie als Nächstes nach dem x-ms-copy-status: success Header. Beachten Sie jedoch, dass alle Schreibvorgänge für ein Blob außer Lease, Put Pageund Put Block alle x-ms-copy-* Eigenschaften aus dem Blob entfernen. Diese Eigenschaften werden auch nicht von Copy Blob Vorgängen kopiert, die frühere Versionen als 2012-02-12 verwenden.

x-ms-copy-status-description enthält weitere Informationen zum Fehler bei Copy Blob. Die x-ms-copy-status-description Werte werden in der folgenden Tabelle beschrieben:

Komponente	BESCHREIBUNG
HTTP-Statuscode	Eine standardmäßige dreistellige ganzzahlige Zahl, die den Fehler angibt.
Fehlercode	Eine Schlüsselwort (keyword), die den von Azure im <ErrorCode-Element> bereitgestellten Fehler beschreibt. Wenn kein <ErrorCode-Element> angezeigt wird, wird ein Schlüsselwort (keyword) mit Standardfehlertext verwendet, der dem 3-stelligen HTTP-status-Code in der HTTP-Spezifikation zugeordnet ist. Weitere Informationen finden Sie unter Bekannte REST API-Fehlercodes.
Information	Detaillierte Beschreibung des Fehlers, in Anführungszeichen eingeschlossen.

Die x-ms-copy-status Werte und x-ms-copy-status-description allgemeiner Fehlerszenarien werden in der folgenden Tabelle beschrieben:

Wichtig

Die folgenden Fehlerbeschreibungen können sich auch ohne Versionsänderung ohne Warnung ändern, sodass der Text möglicherweise nicht genau übereinstimmt.

Szenario	x-ms-copy-status-Wert	x-ms-copy-status-description-Wert
Der Kopiervorgang wurde erfolgreich abgeschlossen.	success	empty
Der Kopiervorgang wurde vom Benutzer abgebrochen.	aborted	empty
Beim Lesen aus dem Quell-BLOB während eines Kopiervorgangs ist ein Fehler aufgetreten, der Vorgang wird jedoch wiederholt.	pending	502 BadGateway "Wiederholbarer Fehler beim Lesen der Quelle. Es wird versucht, den Vorgang zu wiederholen. Fehlerzeit: <Zeit>"
Beim Schreiben in das Ziel-BLOB eines Kopiervorgangs ist ein Fehler aufgetreten, der Vorgang wird jedoch wiederholt.	pending	500 InternalServerError "Wiederholbarer Fehler. Es wird versucht, den Vorgang zu wiederholen. Fehlerzeit: <Zeit>"
Beim Lesen aus dem Quell-BLOB eines Kopiervorgangs ist ein nicht behebbarer Fehler aufgetreten.	„Fehlgeschlagen“	404 ResourceNotFound "Fehler beim Lesen der Quelle beim Kopieren". Hinweis: Wenn der Dienst diesen zugrunde liegenden Fehler meldet, wird er im <ErrorCode-Element> zurückgegeben`ResourceNotFound`. Wenn in der Antwort kein <ErrorCode-Element> angezeigt wird, wird eine Standardzeichenfolgendarstellung der HTTP-status angezeigt, z`NotFound`. B. .
Das Timeout, das alle Kopiervorgänge einschränkt, ist abgelaufen. (Derzeit beträgt der Timeoutzeitraum zwei Wochen.)	„Fehlgeschlagen“	500 OperationCancelled "Die maximal zulässige Zeit für den Kopiervorgang wurde überschritten."
Der Kopiervorgang ist beim Lesen aus der Quelle zu oft fehlgeschlagen, und er erfüllte kein Mindestverhältnis von Versuchen zu Erfolgen. (Dieses Timeout verhindert, dass eine sehr schlechte Quelle über zwei Wochen wiederholt wird, bevor ein Fehler auftritt.)	„Fehlgeschlagen“	500 OperationCancelled "Fehler beim Kopieren während des Lesens der Quelle."

x-ms-last-access-time verfolgt den Zeitpunkt, zu dem auf die Daten des Blobs zugegriffen wurde, basierend auf der Richtlinie zur letzten Zugriffszeitüberwachung des Speicherkontos. Der Zugriff auf die Metadaten eines Blobs ändert nicht die Uhrzeit des letzten Zugriffs.

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 Get Blob Properties Anforderungen basierend auf dem Speicherkontotyp:

Vorgang	Speicherkontotyp	Abrechnungskategorie
Get Blob Properties	Premium, Blockblob Standard „Allgemein v2“	Weitere Vorgänge
Get Blob Properties	Standard „Allgemein v1“	Dient zum Lesen von Vorgängen.

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

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes