Freigeben über

Blob-Eigenschaften abrufen

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

Request

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.

Anforderungs-URI der HEAD-Methode 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 senden, geben Sie den Hostnamen des Emulators und den Azure Blob Storage-Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

Anforderungs-URI der HEAD-Methode 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 parameters

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

Parameter Description
snapshot Optional. Der snapshot-Parameter ist ein nicht transparenter DateTime Wert, der, wenn er vorhanden ist, die abzurufende Blobmomentaufnahme angibt. Weitere Informationen zum Arbeiten mit Blobmomentaufnahmen finden Sie unter Erstellen einer Momentaufnahme eines Blobs.
versionid Optional. Version 2019-12-12 und höher. Bei dem versionid Parameter handelt es sich um einen nicht transparenten DateTime Wert, der, wenn er vorhanden ist, die Version des abzurufenden Blobs angibt.
timeout Optional. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Request headers

In der folgenden Tabelle werden die erforderlichen und optionalen Anforderungsheader beschrieben.

Request header Description
Authorization Required. 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 Required. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Optional für anonyme Anfragen. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-lease-id: <ID> Optional. Wenn dieser Header angegeben ist, wird der Get Blob Properties Vorgang nur ausgeführt, wenn die beiden folgenden Bedingungen erfüllt sind:

- Die Lease des Blobs ist derzeit aktiv.
- Die Lease-ID, die in der Anforderung angegeben ist, stimmt mit der Lease-ID des Blobs überein.

Wenn eine dieser Bedingungen nicht erfüllt ist, schlägt die Anforderung fehl, und der Get Blob Properties Vorgang schlägt mit dem Statuscode 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 true, werden die Benutzeridentitätswerte, die in den x-ms-ownerKopfzeilen und Antwortheader zurückgegeben werden, x-ms-groupx-ms-acl von Microsoft Entra Objekt-IDs in Benutzerprinzipalnamen transformiert. Wenn der Wert false ist, 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 Speicheranalyseprotokollierung 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 auch die Verwendung von bedingten Headern, um Blobeigenschaften und Metadaten nur dann zurückzugeben, 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 in der 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.

Request header Description
x-ms-encryption-key Required. 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 Required. Gibt den Algorithmus an, der für die Verschlüsselung verwendet werden soll. Der Wert dieses Headers muss auf AES256 festgelegt sein.

Request body

None.

Response

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

Status code

Ein erfolgreicher Vorgang gibt den Statuscode 200 (OK) zurück.

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

Response headers

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

Response header Description
Last-Modified Das Datum/die Uhrzeit, zu der das Blob zuletzt geändert wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.

Jeder Vorgang, der das Blob ändert, einschließlich einer Aktualisierung der Metadaten oder Eigenschaften des Blobs, ändert den Zeitpunkt der letzten Änderung des Blobs.

Beachten Sie, dass dies Last-Modified für verwaltete Datenträger und Momentaufnahmen verwalteter Datenträger, die größer als 4 TiB sind, nicht zurückgegeben wird.
x-ms-creation-time Version 2017-11-09 und höher. Das Datum/die Uhrzeit, zu der das Blob erstellt wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.
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, wird die Anzahl der Tags zurückgegeben, die im Blob gespeichert sind. Dieser Header wird nicht zurückgegeben, wenn das Blob keine Tags enthält.
x-ms-blob-type:<BlockBlob\|PageBlob\|AppendBlob> Der BLOB-Typ.
x-ms-copy-completion-time:<datetime> Version 2012-02-12 und höher. Abschlusszeit des letzten versuchten Copy Blob Vorgangs, bei dem dieses Blob das Zielblob war. Dieser Wert kann den Zeitpunkt 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 Set Blob Properties, Put Bloboder Put Block Listverwendet.
x-ms-copy-status-description: <error string> Version 2012-02-12 und höher. Wird nur angezeigt, wenn x-ms-copy-status ist failed oder pending. Beschreibt die Ursache eines schwerwiegenden oder nicht schwerwiegenden Fehlers beim Kopiervorgang. 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-id: <id> Version 2012-02-12 und höher. Der Zeichenfolgenbezeichner für den letzten Versuch, den Vorgang auszuführen Copy Blob , 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-progress: <bytes copied/bytes total> Version 2012-02-12 und höher. Enthält die Anzahl der kopierten Bytes und die Gesamtzahl der Bytes in der Quelle im letzten versuchten Copy Blob Vorgang, wobei dieses Blob das Zielblob war. Kann von 0 bis zu Content-Length kopierten 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-source: url Version 2012-02-12 und höher. Eine URL mit einer Länge von bis zu 2 KB, die das Quellblob angibt, das beim letzten Versuch Copy Blob des Vorgangs 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-copy-status: <pending \| success \| aborted \| failed> Version 2012-02-12 und höher. Der Status des Kopiervorgangs, der durch x-ms-copy-id identifiziert wird, mit den folgenden Werten:

- success: Der Kopiervorgang wurde erfolgreich abgeschlossen.
- pending: Der Kopiervorgang wird ausgeführt. Überprüfen Sie x-ms-copy-status-description , ob zeitweilige, nicht schwerwiegende Fehler den Kopiervorgang behindern, aber keine Fehler verursachen.
- aborted: Der Kopiervorgang wurde um Abort Copy Blobbeendet.
- failed: Kopieren fehlgeschlagen. Details zu Fehlern finden Sie unter 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 Set Blob Properties, Put Bloboder Put Block List.
x-ms-incremental-copy: true Version 2016-05-31 und höher. Eingeschlossen, 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 es sich bei dem Blob um ein inkrementelles Kopierblob oder eine inkrementelle Kopiermomentaufnahme handelt, wenn x-ms-copy-status es sich um einen Erfolg handelt. Momentaufnahmezeit der letzten erfolgreichen inkrementellen Kopiermomentaufnahme für dieses Blob.
x-ms-lease-duration: <infinite \| fixed> Wenn ein Blob geleast wird, gibt sie an, ob die Lease unendlich 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 Blobs.
Content-Length Die Größe des Blobs in Byte. Für ein 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 ist. Wenn kein Inhaltstyp angegeben ist, wird der Standardinhaltstyp application/octet-stream.
Etag Das ETag enthält einen Wert, den Sie zum bedingten Ausführen von Vorgängen verwenden können. 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.

In Version 2012-02-12 und höher wird der MD5-Wert eines Blockblobs auch dann festgelegt, Put Blob wenn die Put Blob Anforderung keinen MD5-Header enthält.
Content-Encoding Wenn der Content-Encoding Anforderungsheader zuvor für das Blob festgelegt wurde, wird dieser Wert in diesem Header zurückgegeben.
Content-Language Wenn der Content-Language Anforderungsheader zuvor für das Blob festgelegt wurde, wird dieser Wert in diesem Header zurückgegeben.
Content-Disposition Wenn der Content-Disposition Anforderungsheader zuvor für das Blob festgelegt wurde, wird dieser Wert in diesem Header für Anforderungen für Version 2013-08-15 und höher zurückgegeben.

Das Content-Disposition Antwort-Header-Feld enthält zusätzliche Informationen darüber, wie die Antwortnutzlast verarbeitet werden soll, und kann auch zum Anhängen zusätzlicher Metadaten verwendet werden. Wenn der Header z. B. auf attachmentfestgelegt ist, bedeutet dies, dass der Benutzeragent die Antwort nicht anzeigen soll, sondern stattdessen das Dialogfeld Speichern unter.
Cache-Control Wenn der Cache-Control Anforderungsheader zuvor 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 für Blockblobs oder Anfügeblobs nicht zurückgegeben.

Dieser Header wird für Blockblobs nicht zurückgegeben.
x-ms-request-id Dieser Header identifiziert die gestellte Anforderung eindeutig, und Sie können ihn zur Fehlerbehebung der Anforderung verwenden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
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 für Version 2009-09-19 und höher gestellt werden.

Dieser Header wird auch für anonyme Anforderungen ohne angegebene Version zurückgegeben, wenn der Container mithilfe von Blob Storage Version 2009-09-19 für den öffentlichen Zugriff markiert wurde.
Date Ein vom Dienst generierter UTC-Wert für Datum/Uhrzeit, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde.
Accept-Ranges: bytes Gibt an, dass der Dienst Anforderungen für partielle BLOB-Inhalte unterstützt. Enthalten für Anforderungen, die mit Version 2013-08-15 und höher gestellt wurden.
x-ms-blob-committed-block-count Die Anzahl der zugesicherten 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 den Wert 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 wird, wird der festgelegte Wert zurückgegeben. Nur gültig, wenn der hierarchische 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 in einem Storage Premium-Konto oder der Ebene eines Blockblobs in einem Blob Storage-Konto oder einem Konto vom Typ "Universell v2". Eine Liste der zulässigen Premium-Seiten-BLOB-Ebenen finden Sie unter High-Performance Premium Storage und verwaltete Datenträger für VMs. Bei Blob-Speicher- oder allgemeinem v2-Konto sind gültige Werte Hot, Cool, Coldund Archive. Hinweis:Cold Ebene wird für Version 2021-12-02 und höher unterstützt. Ausführliche Informationen zum standardmäßigen Tiering auf Blockblobebene für Blobkonten finden Sie unter Speicherebenen "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 .true Wenn für Blockblobs in Blob Storage oder einem Konto vom Typ "Universell v2" für das Blob die Zugriffsebene nicht 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 ein Konto vom Typ "Universell v2" sind rehydrate-pending-to-hotdie gültigen Werte , rehydrate-pending-to-coolund rehydrate-pending-to-cold. Wenn das Blob aktiviert wird und unvollständig ist, wird dieser Header zurückgegeben, der sowohl angibt, dass die Aktivierung aussteht, als auch die Zielebene anzeigt. Ausführliche Informationen zum standardmäßigen Blocktiering auf Blobebene für Blobkonten finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".
x-ms-access-tier-change-time Version 2017-04-17 und höher. Gibt an, wann die Ebene für das Objekt zuletzt geändert wurde. Dieser Header wird nur zurückgegeben, wenn jemals eine Ebene für das Blockblob festgelegt wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen. Weitere Informationen zum standardmäßigen Blocktiering auf Blobebene für Blobkonten finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".
x-ms-client-request-id Kann verwendet werden, um Anfragen und die entsprechenden Antworten zu behandeln. Der Wert dieses Headers entspricht dem Wert des Headers x-ms-client-request-id , wenn er in der Anforderung vorhanden ist, und der Wert beträgt höchstens 1.024 sichtbare ASCII-Zeichen. 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 ausstehenden Zustand rehydratisiert, wird dieser Header mit der Priorität des Rehydrats zurückgegeben. Gültige Werte sind High/Standard. Ausführliche Informationen zum standardmäßigen Tiering auf Blockblobebene für Blobkonten finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".
x-ms-or-{policy-id}_{rule-id} Version 2019-12-12 und höher, wird 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 für den Blobcontainer darstellt. Wenn das Konto -enabled ist ObjectReplication, stellt der Wert dieses Headers den Replikationsstatus 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, wird nur für Blockblobs zurückgegeben. Wenn das Konto aktiviert ist ObjectReplication, stellt der Wert dieses Headers die Richtlinie dar, die die Replizierung steuert.
x-ms-last-access-time Version 2020-02-10 und höher. Gibt an, wann das letzte Mal auf die Daten des Blobs zugegriffen wurde, basierend auf der Richtlinie für die Nachverfolgungszeit des letzten Zugriffs des Speicherkontos. Der Header wird nicht zurückgegeben, wenn das Speicherkonto nicht über eine Richtlinie für die Nachverfolgung der Zeit des letzten Zugriffs verfügt oder die Richtlinie deaktiviert ist. Informationen zum Festlegen der Richtlinie für die Nachverfolgungszeit des Speicherkontos für den letzten Zugriff finden Sie unter Blob Storage-API.
x-ms-blob-sealed Version 2019-12-12 und höher, die nur für Anfügeblobs zurückgegeben wird. Wenn das Anfügeblob versiegelt wurde, wäre 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 hat das Format RFC1123.
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. Die Werte sind unlocked/locked. unlocked Gibt an, dass der Benutzer die Richtlinie ändern kann, indem er das Aufbewahrungsdatum 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 keine gesetzliche Aufbewahrungspflicht für das Blob vorhanden ist. Der Wert dieses Headers wird auf true festgelegt, wenn das Blob eine gesetzliche Aufbewahrungspflicht enthält und der Wert true ist. Andernfalls wird der Wert auf false festgelegt, wenn das Blob eine gesetzliche Aufbewahrungspflicht enthält und der Wert false ist.
x-ms-owner Version 2020-06-12 und höher. Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt den Besitzerbenutzer der Datei oder des Verzeichnisses zurück.
x-ms-group Version 2020-06-12 und höher. Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt die Besitzergruppe der Datei oder des Verzeichnisses zurück.
x-ms-permissions Version 2020-06-12 und höher. Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt die Berechtigungen zurück, die für Benutzer, Gruppen und andere für die Datei oder das Verzeichnis festgelegt sind. Jede einzelne Berechtigung hat ein [r,w,x,-]{3} Format.
x-ms-acl Version 2023-11-03 und höher. Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt die kombinierte Liste der Zugriffs- und Standardzugriffssteuerungslisten zurück, die für Benutzer, Gruppen und andere für die Datei oder das Verzeichnis festgelegt sind. Jeder Zugriffssteuerungseintrag (Access Control Entry, ACE) besteht aus einem Bereich, einem Typ, einer Benutzer- oder Gruppenkennung und Berechtigungen im Format [scope]:[type]:[id]:[permissions]. Der default Bereich gibt an, dass der ACE zur Standard-ACL für ein Verzeichnis gehört. Andernfalls ist der Bereich implizit, und der ACE gehört zur Zugriffs-ACL. Jede einzelne Berechtigung hat ein [r,w,x,-]{3} Format.
x-ms-resource-type Version 2020-10-02 und höher. Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt den Ressourcentyp für den Pfad zurück, der entweder file oder sein directorykann.
x-ms-expiry-time Version 2020-02-10 und höher. Nur für Konten mit aktiviertem hierarchischem Namespace. Gibt die Ablaufzeit zurück, die für das Blob festgelegt ist. Wird nur für Dateien zurückgegeben, für die eine Ablaufzeit festgelegt ist.

Response body

None.

Sample response

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

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

Important

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

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

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

Permissions

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 Get Blob Properties Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

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

Remarks

Um zu bestimmen, ob ein Copy Blob Vorgang abgeschlossen ist, stellen Sie zunächst sicher, dass der x-ms-copy-id Headerwert mit der Kopien-ID übereinstimmt, die vom ursprünglichen Aufruf von Copy Blobbereitgestellt wird. Eine Übereinstimmung stellt sicher, dass eine andere Anwendung den Kopiervorgang nicht abgebrochen und einen neuen Copy Blob Vorgang gestartet hat. Überprüfen Sie als Nächstes, ob die Kopfzeile vorhanden ist x-ms-copy-status: success . Beachten Sie jedoch, dass alle Schreibvorgänge für ein Blob mit Ausnahme Leasevon , Put Pageund Put Block alle Eigenschaften aus dem Blob entfernen x-ms-copy-* . 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 Copy Blob Fehler. Die x-ms-copy-status-description Werte sind in der folgenden Tabelle beschrieben:

Component Description
HTTP-Statuscode Eine standardmäßige 3-stellige Ganzzahl, die den Fehler angibt.
Error code Ein Schlüsselwort, das den Fehler beschreibt, der <von Azure im ErrorCode-Element> bereitgestellt wird. Wenn kein <ErrorCode-Element> angezeigt wird, wird ein Schlüsselwort mit Standardfehlertext verwendet, der dem 3-stelligen HTTP-Statuscode in der HTTP-Spezifikation zugeordnet ist. Weitere Informationen finden Sie unter Bekannte REST API-Fehlercodes.
Information Detaillierte Beschreibung des Fehlers in Anführungszeichen.

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

Important

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

Scenario x-ms-copy-status value x-ms-copy-status-description value
Der Kopiervorgang wurde erfolgreich abgeschlossen. success empty
Der Benutzer hat den Kopiervorgang abgebrochen, bevor er abgeschlossen wurde. aborted empty
Beim Lesen aus dem Quellblob während eines Kopiervorgangs ist ein Fehler aufgetreten, der Vorgang wird jedoch wiederholt. pending 502 BadGateway "Beim Lesen der Quelle ist ein erneuter Fehler aufgetreten. Will retry. Zeitpunkt des Versagens: <Zeit>"
Beim Schreiben in das Zielblob eines Kopiervorgangs ist ein Fehler aufgetreten, der Vorgang wird jedoch wiederholt. pending 500 InternalServerError "Es ist ein erneuter Fehler aufgetreten. Will retry. Zeitpunkt des Versagens: <Zeit>"
Beim Lesen aus dem Quell-BLOB eines Kopiervorgangs ist ein nicht wiederherstellbarer Fehler aufgetreten. failed 404 ResourceNotFound, "Kopieren beim Lesen des Quellcodes fehlgeschlagen." Hinweis: Wenn der Dienst diesen zugrunde liegenden Fehler meldet, wird er <im ErrorCode-Element> zurückgegebenResourceNotFound. Wenn kein <ErrorCode-Element> in der Antwort angezeigt wird, wird eine standardmäßige Zeichenfolgendarstellung des HTTP-Status angezeigt, z. B NotFound. . .
Der Timeoutzeitraum, der alle verstrichenen Kopiervorgänge begrenzt. (Derzeit beträgt die Zeitüberschreitung zwei Wochen.) failed 500 OperationCancelled "Die Kopie hat die maximal zulässige Zeit überschritten."
Der Kopiervorgang schlug beim Lesen aus der Quelle zu oft fehl, und es wurde ein Mindestverhältnis von Versuchen zu Erfolgen nicht erreicht. (Dieses Timeout verhindert, dass eine sehr schlechte Quelle mehr als zwei Wochen vor dem Fehlschlagen versucht wird). failed 500 OperationCancelled "Fehler beim Lesen der Quelle."

x-ms-last-access-time Verfolgt den Zeitpunkt, zu dem auf die Daten des Blobs zugegriffen wurde, basierend auf der Richtlinie für die Nachverfolgung des letzten Zugriffs des Speicherkontos. Durch den Zugriff auf die Metadaten eines Blobs wird die Uhrzeit des letzten Zugriffs nicht geändert.

Billing

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. Diese Anforderungen anfallen Gebühren pro Transaktion. Der Transaktionstyp wirkt sich auf die Belastung des Kontos aus. Lesen Sie z. B. Transaktionen, die einer anderen Abrechnungskategorie als dem Schreiben von Transaktionen zugerechnet werden. Die folgende Tabelle zeigt die Abrechnungskategorie für Get Blob Properties Anforderungen basierend auf dem Speicherkontotyp:

Operation Speicherkontotyp Billing category
Blob-Eigenschaften abrufen Premium-Blockblob
Standard, Universell V2		 Other operations
Blob-Eigenschaften abrufen Standard „Allgemein v1“ Read operations

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

See also

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