Freigeben über

Get Blob Properties

  • Artikel

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 für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators 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 Momentaufnahme-Parameter ist ein undurchsichtiger DateTime Wert, der, wenn er vorhanden ist, die abzurufende Blob-Momentaufnahme angibt. Weitere Informationen zum Arbeiten mit Blobmomentaufnahmen finden Sie unter Create 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 hierarchischen Namespace. Wenn true, werden die In- x-ms-ownerx-ms-group und x-ms-acl Antwortheader zurückgegebenen Benutzeridentitätswerte 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 aufweisen.
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 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 zum Lesen eines Blobs angeben, das mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt ist. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und der entsprechenden Gruppe 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 Eine Reihe 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 Bloboder Put Block ListverwendetSet 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 pendingistfailed. Beschreibt die Ursache eines schwerwiegenden oder nicht schwerwiegenden 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 Bloboder Put Block ListverwendetSet Blob Properties.
x-ms-copy-id: <id> Version 2012-02-12 und höher. Der Zeichenfolgenbezeichner für den letzten versuchten Copy Blob Vorgang, 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 Bloboder Put Block ListverwendetSet 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 Gesamtbytes 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 , Put Bloboder Put Block ListverwendetSet 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 im 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 Bloboder Put Block ListverwendetSet Blob Properties.
x-ms-copy-status: <pending \| success \| aborted \| failed> Version 2012-02-12 und höher. Der Status des Kopiervorgangs, der von x-ms-copy-id mit den folgenden Werten identifiziert wird:

- success: Der Kopiervorgang wurde erfolgreich abgeschlossen.
- pending: Das Kopieren wird ausgeführt. Überprüfen Sie x-ms-copy-status-description. Zeitweilige, nicht schwerwiegende Fehler behindern den Kopiervorgang, verursachen jedoch keinen Fehler.
- aborted: Der Kopiervorgang wurde durch Abort Copy Blobbeendet.
- 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 Bloboder Put Block ListverwendetSet Blob Properties.
x-ms-incremental-copy: true Version 2016-05-31 und höher. Wird 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. Wird eingeschlossen, wenn das Blob ein inkrementelles Kopierblob oder ein inkrementelles Kopierblob Momentaufnahme ist, wenn x-ms-copy-status erfolgreich ist. Momentaufnahmezeit des letzten erfolgreichen inkrementellen Kopiervorgangs 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. 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 wird. Wenn kein Inhaltstyp angegeben ist, ist application/octet-streamder 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 attachmentfestgelegt ist, gibt dies an, dass der Benutzer-Agent die Antwort nicht anzeigen, 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 die durchgeführte Anforderung eindeutig, und Sie können ihn zur Problembehandlung für die 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 ausgeführt 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 öffentlichen Zugriff markiert wurde.
Date Ein vom Dienst generierter UTC-Datums-/Uhrzeitwert, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde.
Accept-Ranges: bytes Gibt an, dass der Dienst Anforderungen für teilweisen BLOB-Inhalt unterstützt. Enthalten für Anforderungen mit Version 2013-08-15 und höher.
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 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 auf einem Storage Premium Konto oder ebene eines Blockblobs in einem Blob Storage- oder universell v2-Konto. 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 universelle v2-Konten sind Hotgültige Werte , Cool, Coldund Archive. Hinweis:Cold tier wird für Version 2021-12-02 und höher unterstützt. Ausführliche Informationen zum Blockblobebenen-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. Bei Blockblobs in Blob Storage oder einem Konto vom Typ "Universell v2" können Sie die Ebene aus den Speicherkontoeigenschaften ableiten, wenn für das Blob nicht die Zugriffsebene festgelegt ist. 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 universelle v2-Konten sind rehydrate-pending-to-hotgültige Werte , rehydrate-pending-to-coolund rehydrate-pending-to-cold. Wenn das Blob rehydriert wird und unvollständig ist, wird dieser Header zurückgegeben, was sowohl angibt, dass die Aktivierung aussteht, als auch die Zielebene anzeigt. Ausführliche Informationen zum Standard-Blobkontoblock-Tiering auf Blobebene finden Sie unter Speicherebene "Heiß", "Kalt" und "Archiv".
x-ms-access-tier-change-time Version 2017-04-17 und höher. Gibt an, zu welcher Zeit die Ebene zuletzt für das Objekt geändert wurde. Dieser Header wird nur zurückgegeben, wenn jemals eine Ebene für Blockblobs festgelegt wurde. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Headern. Weitere Informationen zum Standard-Blobkontoblock-Tiering auf Blobebene finden Sie unter Speicherebene "Heiß", "Kalt" und "Archiv".
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 istObjectReplication, 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 mit aktiviertem hierarchischen 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 hierarchischen 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 hierarchischen Namespace. 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 ein [r,w,x,-]{3} Format.
x-ms-acl Version 2023-11-03 und höher. Nur für Konten mit aktiviertem hierarchischen Namespace. Gibt die kombinierte Liste der Zugriffs- und Standardzugriffssteuerungsliste zurück, die für Benutzer, Gruppe und andere in der Datei oder dem Verzeichnis festgelegt sind. Jeder Zugriffssteuerungseintrag (Access Control Entry, ACE) besteht aus einem Bereich, einem Typ, einem Benutzer- oder Gruppenbezeichner 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, für die ein hierarchischer Namespace aktiviert ist. 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, 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.

Wichtig

Microsoft empfiehlt die Verwendung 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 überlegene Sicherheit und Benutzerfreundlichkeit.

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

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, Gruppe, verwaltete Identität oder 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:

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

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ückgegebenResourceNotFound. Wenn in der Antwort kein <ErrorCode-Element> angezeigt wird, wird eine Standardzeichenfolgendarstellung der HTTP-status angezeigt, zNotFound. 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