Blob von URL ablegen

Artikel
10/22/2024

Der vorgang Put Blob From URL erstellt ein neues Block-BLOB, in dem der Inhalt des Blobs aus einer angegebenen URL gelesen wird. Diese API ist ab Version 2020-04-08 verfügbar.

Partielle Updates werden mit Put Blob From URLnicht unterstützt. Der Inhalt eines vorhandenen Blobs wird mit dem Inhalt des neuen Blobs überschrieben. Verwenden Sie die Put Block From URL-API in Verbindung mit Put Block List, um Teilaktualisierungen für den Inhalt eines Block-Blobs mithilfe einer Quell-URL auszuführen.

Die Größe des Quell-BLOB kann bis zu einer maximalen Länge von 5.000 Mebibyte (MiB) betragen.

Anforderung

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

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

Emulierte Speicherdienstanforderung

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und den Blob-Dienstport als 127.0.0.1:10000an, gefolgt vom emulierten Speicherkontonamen:

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

Der Speicher-Emulator unterstützt nur BLOB-Größen von bis zu 2 Gibibytes (GiB).

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

URI-Parameter

Die folgenden zusätzlichen Parameter können für den Anforderungs-URI angegeben werden:

Parameter	Beschreibung
`timeout`	Optional. Der parameter `timeout` wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob-Dienstvorgänge.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungsheader	Beschreibung
`Authorization`	Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
`Date` oder `x-ms-date`	Erforderlich. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
`x-ms-version`	Erforderlich für alle autorisierten Anforderungen. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
`Content-Length`	Erforderlich. Gibt die Anzahl der Im Anforderungstext übertragenen Bytes an. Der Wert dieses Headers muss auf 0 festgelegt werden. Wenn die Länge nicht 0 ist, schlägt der Vorgang mit dem Statuscode 400 (Ungültige Anforderung) fehl.
`x-ms-copy-source:name`	Erforderlich. Gibt die URL des Quell-BLOB an. Der Wert kann eine URL von bis zu 2 Kibibytes (KiB) sein, die ein Blob angibt. Der Wert sollte URL-codiert sein, wie er in einem Anforderungs-URI angezeigt wird. Das Quell-BLOB muss entweder öffentlich sein oder über eine Freigegebene Zugriffssignatur autorisiert werden. Wenn das Quell-BLOB öffentlich ist, ist keine Autorisierung erforderlich, um den Vorgang auszuführen. Wenn die Größe des Quell-BLOB größer als 5000 MiB ist oder wenn die Quelle keinen gültigen `Content-Length`-Wert zurückgibt, schlägt die Anforderung mit dem Statuscode 409 (Conflict) fehl. Hier sind einige Beispiele für Quellobjekt-URLs: - `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>`
`x-ms-copy-source-authorization: <scheme> <signature>`	Optional. Gibt das Autorisierungsschema und die Signatur für die Kopierquelle an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage. Hinweis: Für Microsoft Entra wird nur ein Bearerschema unterstützt. Hinweis: Wenn ihr Quellobjekt öffentlich zugänglich ist oder sich Ihr Quellobjekt in einem Speicherkonto befindet und Sie ein SAS-Token verwenden, das in `x-ms-copy-source:name`übergeben wird, ist dieser Header nicht erforderlich. Dieser Header wird in Den Versionen 2020-10-02 und höher unterstützt.
`x-ms-blob-type: BlockBlob`	Erforderlich. Gibt den Typ des zu erstellenden Blobs an, der `BlockBlob`sein muss. Wenn der BLOB-Typ nicht `BlockBlob`ist, schlägt der Vorgang mit dem Statuscode 400 (Ungültige Anforderung) fehl.
`Content-Type`	Optional. Der MIME-Inhaltstyp des Blobs. Der Standardtyp ist `application/octet-stream`.
`Content-Encoding`	Optional. Gibt an, welche Inhaltscodierungen auf das Blob angewendet wurden. Dieser Wert wird an den Client zurückgegeben, wenn der vorgang Get Blob für die BLOB-Ressource ausgeführt wird. Wenn dieser Wert zurückgegeben wird, kann der Client ihn verwenden, um den BLOB-Inhalt zu decodieren.
`Content-Language`	Optional. Gibt die von dieser Ressource verwendeten natürlichen Sprachen an.
`Cache-Control`	Optional. Blob Storage speichert diesen Wert, verwendet oder ändert ihn jedoch nicht.
`x-ms-source-content-md5`	Optional. Ein MD5-Hash des BLOB-Inhalts aus dem URI. Dieser Hash wird verwendet, um die Integrität des Blobs während des Transports der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der von der Kopierquelle mit diesem Headerwert eingegangen ist. Wenn dieser Header ausgelassen wird, generiert Blob Storage einen MD5-Hash. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.
`x-ms-content-crc64`	Optional. Ein CRC64-Hash des BLOB-Inhalts. Dieser Hash wird verwendet, um die Integrität des Blobs während des Transports zu überprüfen. Wenn dieser Header angegeben ist, überprüft der Speicherdienst den Hash, der für den gesendeten Header eingetroffen ist. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl. Dieser Header wird in Version 02-02-2019 und höher unterstützt. Wenn sowohl Content-MD5- als auch x-ms-content-crc64-Header vorhanden sind, schlägt die Anforderung mit einer 400 (ungültige Anforderung) fehl.
`x-ms-blob-content-type`	Optional. Legt den Inhaltstyp des Blobs fest.
`x-ms-blob-content-encoding`	Optional. Legt die Inhaltscodierung des Blobs fest.
`x-ms-blob-content-language`	Optional. Legt die Inhaltssprache des Blobs fest.
`x-ms-blob-content-md5`	Optional. Legt den MD5-Hash des Blobs fest.
`x-ms-blob-cache-control`	Optional. Legt das Cachesteuerelement des Blobs fest.
`x-ms-meta-name:value`	Optional. Die Name-Wert-Paare, die dem Blob als Metadaten zugeordnet sind. Hinweis: Ab Version 2009-09-19 müssen Metadatennamen den Benennungsregeln für C#-Bezeichnerentsprechen.
`x-ms-encryption-scope`	Optional. Der Verschlüsselungsbereich, der zum Verschlüsseln des Anforderungsinhalts verwendet werden soll. Dieser Header wird in Version 2019-02-02 und höher unterstützt.
`x-ms-tags`	Optional. Legt die angegebenen, abfragezeichenfolgencodierten Tags für das Blob fest. Weitere Informationen finden Sie im Abschnitt Anmerkungen. Unterstützt in Version 2019-12-12 und höher.
`x-ms-copy-source-tag-option`	Optional. Mögliche Werte sind REPLACE oder COPY (Groß-/Kleinschreibung wird beachtet). Der Standardwert ist REPLACE. Wenn COPY angegeben ist, werden die Tags aus dem Quell-BLOB in das Ziel-Blob kopiert. Das Quell-BLOB muss privat sein, und die Anforderung muss über die Berechtigung zum Abrufen von Blobtags im Quell-Blob verfügen und Blobtags für das Ziel-Blob festlegen. Dies verursacht einen zusätzlichen Aufruf des Abrufen von BLOB-Tags Vorgangs für das Quellkonto. REPLACE legt Tags fest, die vom `x-ms-tags` Header im Ziel-BLOB angegeben werden. Wenn REPLACE verwendet wird und keine Tags durch `x-ms-tags`angegeben werden, werden keine Tags für das Ziel-BLOB festgelegt. Das Angeben von COPY und `x-ms-tags` führt zu einem 409 (Konflikt). Unterstützt in Version 2021-04-10 und höher.
`x-ms-copy-source-blob-properties`	Optional. Gibt das Verhalten der Kopierquell-BLOB-Eigenschaften an. Bei Festlegung auf `True`werden die Eigenschaften des Quellblobs in das neue Blob kopiert. Standardwert: `True`.
`x-ms-source-if-modified-since`	Optional. Ein `DateTime`-Wert. Geben Sie diesen bedingten Header an, um das Blob nur zu platzieren, wenn das Quell-BLOB seit dem angegebenen Datum/der angegebenen Uhrzeit geändert wurde. Wenn das Quell-BLOB nicht geändert wurde, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen). Dieser Header kann nicht angegeben werden, wenn es sich bei der Quelle um eine Azure Files-Freigabe handelt.
`x-ms-source-if-unmodified-since`	Optional. Ein `DateTime`-Wert. Geben Sie diesen bedingten Header an, um das Blob nur zu platzieren, wenn das Quell-Blob seit dem angegebenen Datum/der angegebenen Uhrzeit nicht geändert wurde. Wenn das Quell-BLOB geändert wurde, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen). Dieser Header kann nicht angegeben werden, wenn es sich bei der Quelle um eine Azure Files-Freigabe handelt.
`x-ms-source-if-match`	Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um den Quell-BLOB nur zu platzieren, wenn das ETag mit dem angegebenen Wert übereinstimmt. Wenn die ETag-Werte nicht übereinstimmen, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen). Dieser Header kann nicht angegeben werden, wenn es sich bei der Quelle um eine Azure Files-Freigabe handelt.
`x-ms-source-if-none-match`	Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Blob nur zu platzieren, wenn das ETag nicht mit dem angegebenen Wert übereinstimmt. Wenn die Werte identisch sind, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen). Dieser Header kann nicht angegeben werden, wenn es sich bei der Quelle um eine Azure Files-Freigabe handelt.
`If-Modified-Since`	Optional. Ein `DateTime`-Wert. Geben Sie diesen bedingten Header an, um das Blob nur zu platzieren, wenn das Ziel-BLOB seit dem angegebenen Datum/der angegebenen Uhrzeit geändert wurde. Wenn das Ziel-BLOB nicht geändert wurde, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen).
`If-Unmodified-Since`	Optional. Ein `DateTime`-Wert. Geben Sie diesen bedingten Header an, um den Blob nur zu platzieren, wenn das Ziel-Blob seit dem angegebenen Datum/der angegebenen Uhrzeit nicht geändert wurde. Wenn das Ziel-BLOB geändert wurde, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen).
`If-Match`	Optional. Ein ETag-Wert. Geben Sie einen ETag-Wert für diesen bedingten Header an, um den Blob nur dann einzufügen, wenn der angegebene ETag-Wert dem `ETag` Wert für ein vorhandenes Ziel-BLOB entspricht. Wenn das ETag für das Ziel-BLOB nicht mit dem für `If-Match`angegebenen ETag übereinstimmt, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen).
`If-None-Match`	Optional. Ein ETag-Wert oder das Platzhalterzeichen (). Geben Sie einen ETag-Wert für diesen bedingten Header an, um den Blob nur zu platzieren, wenn der angegebene ETag-Wert nicht mit dem ETag-Wert für das Ziel-BLOB übereinstimmt. Geben Sie das Platzhalterzeichen () an, um den Vorgang nur auszuführen, wenn das Ziel-BLOB nicht vorhanden ist. Wenn die angegebene Bedingung nicht erfüllt ist, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen).
`x-ms-lease-id:<ID>`	Erforderlich, wenn das Blob über eine aktive Lease verfügt. Wenn Sie diesen Vorgang für ein Blob mit einer aktiven Lease ausführen möchten, geben Sie die gültige Lease-ID für diesen Header an.
`x-ms-blob-content-disposition`	Optional. Legt den `Content-Disposition` Header des Blobs fest. Verfügbar für Version 2013-08-15 und höher. Das `Content-Disposition` Antwortheaderfeld vermittelt zusätzliche Informationen zum Verarbeiten der Antwortnutzlast und kann zum Anfügen zusätzlicher Metadaten verwendet werden. Wenn der Header beispielsweise auf `attachment`festgelegt ist, gibt er an, dass der Benutzer-Agent die Antwort nicht anzeigen sollte. Stattdessen sollte ein Dialogfeld "Speichern unter" mit einem anderen Dateinamen als dem angegebenen BLOB-Namen angezeigt werden. Die Antwort der Get Blob und Get Blob Properties-Vorgänge umfasst den `content-disposition` Header.
`Origin`	Optional. Gibt den Ursprung an, von dem die Anforderung ausgestellt wird. Das Vorhandensein dieses Headers führt zu CorS-Headern (Cross-Origin Resource Sharing) für die Antwort. Weitere Informationen finden Sie unter CORS-Unterstützung für die Azure Storage-Dienste.
`x-ms-client-request-id`	Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem 1-Kibibyte-Zeichenlimit (KiB) bereit, das in den Analyseprotokollen aufgezeichnet wird, wenn die Speicheranalyseprotokollierung aktiviert ist. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt.
`x-ms-access-tier`	Optional. Gibt die Ebene an, die für das Blob festgelegt werden soll. Gültige Werte für Block-BLOB-Ebenen sind `Hot`, `Cool`, `Cold`und `Archive`. Hinweis: `Cold` Stufe wird für Version 2021-12-02 und höher unterstützt. `Hot`, `Cool`und `Archive` werden für Version 2018-11-09 und höher unterstützt. Weitere Informationen zum Blockieren von Blob-Ebenen finden Sie unter Hot-, Cool- und Archivspeicherebenen.
`x-ms-expiry-option`	Optional. Version 2023-08-03 und höher. Gibt die Ablaufdatumsoption für die Anforderung an. Weitere Informationen finden Sie unter ExpiryOption. Dieser Header ist für Konten gültig, für die der hierarchische Namespace aktiviert ist.
`x-ms-expiry-time`	Optional. Version 2023-08-03 und höher. Gibt den Zeitpunkt an, zu dem das Blob abläuft. Das Format für das Ablaufdatum variiert je nach `x-ms-expiry-option`. Weitere Informationen finden Sie unter ExpiryOption. Dieser Header ist für Konten gültig, für die der hierarchische Namespace aktiviert ist.

Dieser Vorgang unterstützt auch die Verwendung von bedingten Headern zum Schreiben des Blobs nur, 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)

Die folgenden Header können für die Anforderung angegeben werden, um ein Blob mit einem vom Kunden bereitgestellten Schlüssel zu verschlüsseln. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und der entsprechende Satz von Headern) ist optional.

Anforderungsheader	Beschreibung
`x-ms-encryption-key`	Erforderlich. Der base64-codierte AES-256-Verschlüsselungsschlüssel.
`x-ms-encryption-key-sha256`	Erforderlich. Der base64-codierte SHA256-Hash des Verschlüsselungsschlüssels.
`x-ms-encryption-algorithm: AES256`	Erforderlich. Gibt den Algorithmus an, der für die Verschlüsselung verwendet werden soll. Der Wert dieser Kopfzeile muss `AES256`sein.

Anforderungstext

Keine.

Beispielanforderung

Das folgende Beispiel zeigt eine Anforderung zum Erstellen eines Block-Blobs:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblockblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2020-04-08  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-content-disposition: attachment; filename="fname.ext"  
x-ms-blob-type: BlockBlob  
x-ms-meta-m1: v1  
x-ms-meta-m2: v2  
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Content-Length: 0

Antwort

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

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 201 (Erstellt) zurück.

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

Antwortheader

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

Antwortheader	Beschreibung
`ETag`	Das ETag enthält einen Wert, den der Client verwenden kann, um bedingte `PUT` Vorgänge mithilfe des `If-Match` Anforderungsheaders auszuführen. Der ETag-Wert ist in Anführungszeichen eingeschlossen.
`Last-Modified`	Das Datum/die Uhrzeit der letzten Änderung des Blobs. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen. Jeder Schreibvorgang für das Blob (einschließlich Aktualisierungen der Metadaten oder Eigenschaften des Blobs) ändert die uhrzeit der letzten Änderung des Blobs.
`Content-MD5`	Wird für ein Block-BLOB zurückgegeben, sodass der Client die Integrität von Nachrichteninhalten überprüfen kann. Der `Content-MD5` zurückgegebenen Wert wird von Blob Storage berechnet. Dieser Header wird auch dann zurückgegeben, wenn die Anforderung keine `Content-MD5`- oder `x-ms-blob-content-md5` Header enthält.
`x-ms-content-crc64`	Wird für ein Block-BLOB zurückgegeben, sodass der Client die Integrität von Nachrichteninhalten überprüfen kann. Der `x-ms-content-crc64` zurückgegebenen Wert wird von Blob Storage berechnet. Diese Kopfzeile wird immer zurückgegeben.
`x-ms-request-id`	Identifiziert die anforderung eindeutig, die durchgeführt wurde, und Sie können sie verwenden, um die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
`x-ms-version`	Die Version von Blob Storage, die zum Ausführen der Anforderung verwendet wurde.
`Date`	Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
`Access-Control-Allow-Origin`	Wird zurückgegeben, wenn die Anforderung einen `Origin` Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist. Dieser Header gibt den Wert des Ursprungsanforderungsheaders zurück, wenn eine Übereinstimmung vorhanden ist.
`Access-Control-Expose-Headers`	Wird zurückgegeben, wenn die Anforderung einen `Origin` Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist. Gibt die Liste der Antwortheader zurück, die für den Client oder Aussteller der Anforderung verfügbar gemacht werden sollen.
`Access-Control-Allow-Credentials`	Wird zurückgegeben, wenn die Anforderung einen `Origin` Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist, die nicht alle Ursprünge zulässt. Diese Kopfzeile wird auf `true`festgelegt.
`x-ms-request-server-encrypted: true/false`	Der Wert dieses Headers wird auf `true` festgelegt, wenn der Inhalt der Anforderung mithilfe des angegebenen Algorithmus erfolgreich verschlüsselt wird. Andernfalls wird der Wert auf `false`festgelegt.
`x-ms-encryption-key-sha256`	Wird zurückgegeben, wenn die Anforderung einen vom Kunden bereitgestellten Schlüssel für die Verschlüsselung verwendet hat, damit der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des bereitgestellten Schlüssels erfolgreich verschlüsselt wird.
`x-ms-encryption-scope`	Wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, damit der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des Verschlüsselungsbereichs erfolgreich verschlüsselt wird.
`x-ms-version-id: <DateTime>`	Gibt einen undurchsichtigen `DateTime` Wert zurück, der das Blob eindeutig identifiziert. Der Wert dieses Headers gibt die Version des Blobs an und kann in nachfolgenden Anforderungen für den Zugriff auf das Blob verwendet werden.

Antworttext

Keine.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==  
x-ms-content-crc64: 77uWZTolTHU
Date: <date>  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: <date>  
Access-Control-Allow-Origin: http://contoso.com  
Access-Control-Expose-Headers: Content-MD5  
Access-Control-Allow-Credentials: True  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

Autorisierung

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

Wenn eine Anforderung Tags mit dem x-ms-tags Anforderungsheader angibt, muss der Aufrufer die Autorisierungsanforderungen des vorgangs Festlegen von Blobtags erfüllen.

Wichtig

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 für 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.

Berechtigungen

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Put Blob From URL Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

Azure RBAC-Aktion:
- Erstellen eines neuen Block-Blobs: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
- Erstellen eines neuen oder überschreiben eines vorhandenen Block-Blobs: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rolle mit den geringsten Rechten:

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

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

Der Put Blob From URL-Vorgang unterstützt drei Arten von freigegebenen Zugriffssignaturen: SAS-, Dienst-SAS-und Konto SAS.

Als bewährte Methode für die Sicherheit wird empfohlen, microsoft Entra-Anmeldeinformationen anstelle des Speicherkontoschlüssels zu verwenden, der einfacher kompromittiert werden kann. Wenn Für Ihr Anwendungsdesign freigegebene Zugriffssignaturen erforderlich sind, verwenden Sie microsoft Entra-Anmeldeinformationen, um nach Möglichkeit eine Benutzerdelegierungs-SAS zu erstellen.

Wenn der Zugriff auf gemeinsam genutzte Schlüssel für das Speicherkonto unzulässig ist, ist ein Dienst-SAS-Token oder ein Konto-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Verstehen, wie sich die Teilung des freigegebenen Schlüssels auf SAS-Tokenauswirkt.

Sas der Benutzerdelegierung

Eine Benutzerdelegierungs-SAS ist mit Microsoft Entra-Anmeldeinformationen und auch durch die für die SAS angegebenen Berechtigungen gesichert.

Das Aufrufen des Put Blob From URL-Vorgangs mithilfe eines SAS-Tokens, das an einen Container oder eine BLOB-Ressource delegiert wird, erfordert die folgende Berechtigung als Teil des SAS-Tokens der Benutzerdelegierung:

Operation	Signierte Berechtigung
Blob von URL ablegen (neuen Block-Blob erstellen)	Erstellen (c) oder Schreiben (w)
Blob von URL platzieren (vorhandenes Block-Blob überschreiben)	Schreiben (w)

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

Dienst-SAS

Ein Dienst-SAS ist mit dem Speicherkontoschlüssel gesichert. Ein Dienst-SAS delegiert den Zugriff auf eine Ressource in einem einzelnen Azure Storage-Dienst, z. B. Blob-Speicher.

Das Aufrufen des Put Blob From URL Vorgangs mit einem SAS-Token, das an einen Container oder eine Blobressource delegiert wird, erfordert die folgende Berechtigung als Teil des Dienst-SAS-Tokens.

Operation	Signierte Berechtigung
Blob von URL ablegen (neuen Block-Blob erstellen)	Erstellen (c) oder Schreiben (w)
Blob von URL platzieren (vorhandenes Block-Blob überschreiben)	Schreiben (w)

Weitere Informationen zum Dienst SAS finden Sie unter Erstellen eines Dienst-SAS-.

Konto SAS

Ein Konto-SAS ist mit dem Speicherkontoschlüssel gesichert. Ein Konto SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren Speicherdiensten. Alle vorgänge, die über einen Dienst oder eine Benutzerdelegierung SAS verfügbar sind, stehen auch über ein Konto SAS zur Verfügung.

Die folgende Tabelle gibt den signierten Ressourcentyp und die signierten Berechtigungen an, die beim Delegieren des Zugriffs angegeben werden sollen:

Operation	Signierter Dienst	Signierter Ressourcentyp	Signierte Berechtigung
Blob von URL ablegen (neuen Block-Blob erstellen)	Blob (b)	Objekt (o)	Erstellen (c) oder Schreiben (w)
Blob von URL platzieren (vorhandenes Block-Blob überschreiben)	Blob (b)	Objekt (o)	Schreiben (w)

Weitere Informationen zum SAS-Konto finden Sie unter Erstellen eines Kontos sas.

Der Put Blob From URL-Vorgang unterstützt Gemeinsam genutzte Schlüsselautorisierung. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist.

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

Hinweise

Der Put Blob From URL Vorgang wird ab Version 2020-04-08 unterstützt.

In Version 2020-10-02 und höher wird die Microsoft Entra-Autorisierung für die Quelle des Kopiervorgangs unterstützt.

Der Quell-Blob kann beliebiger Art sein, einschließlich eines Block-Blobs, eines Anfüge-Blobs oder eines Seiten-Blobs. Das Ziel-BLOB muss jedoch ein Block-BLOB sein.

Der Put Blob From URL-Vorgang kopiert immer den gesamten Quell-BLOB. Das Kopieren eines Bytebereichs oder einer Gruppe von Blöcken wird nicht unterstützt. Informationen zum Ausführen teilweiser Aktualisierungen finden Sie unter Put Block From URL. Das Ziel-Blob kann ein vorhandenes Block-Blob sein, oder es kann sich um ein neues Blob, das vom Vorgang erstellt wird.

Wenn Sie ein Block-Blob als Quellobjekt verwenden, werden alle zugesicherten BLOB-Inhalte kopiert. Die Blockliste wird jedoch nicht beibehalten, und nicht ausgelassene Blöcke werden nicht kopiert. Der Inhalt des Ziel-BLOB ist identisch mit der der Quelle, die zugesicherte Blockliste wird jedoch nicht beibehalten.

Put Blob-Eigenschaften und Metadaten-

Wenn Sie ein Block-BLOB aus einer Kopierquelle erstellen, werden die Standard-BLOB-Eigenschaften standardmäßig aus dem Quell-BLOB kopiert. Wenn die Anwendungsmetadaten in der Anforderung angegeben werden, wird sie gespeichert, ohne die Quell-BLOB-Metadaten zu kopieren. Um alle HTTP-Inhaltsheader explizit festzulegen, können Sie den entsprechenden Header in der Anforderung angeben.

Content-Type
Content-Encoding
Content-Length
Cache-Control
Content-Disposition

Die Größe des Ziel-BLOB stimmt immer mit dem des Quell-BLOB überein. Der Content-Length-Header muss in der Put Blob From URL Anforderung 0 sein (da kein Anforderungstext vorhanden ist), und die Inhaltslängeneigenschaft für das Ziel-BLOB wird von der Größe der Quelle abgeleitet.

Put Blob From URL custom properties

Put Blob From Url folgt der gleichen Semantik wie Put Blob zum Festlegen benutzerdefinierter Eigenschaften, die standard-HTTP-Headern zugeordnet sind. Weitere Informationen finden Sie unter benutzerdefinierte Blob-Eigenschaften

Blob-Indextags

Wenn Tags für das Ziel-BLOB im x-ms-tags-Header bereitgestellt werden, müssen sie abfragezeichenfolgencodiert sein. Tagschlüssel und -werte müssen den Benennungs- und Längenanforderungen entsprechen, wie in Set Blob Tagsangegeben. Darüber hinaus kann die x-ms-tags Kopfzeile bis zu 2 KiB von Tags enthalten. Wenn weitere Tags erforderlich sind, verwenden Sie den Set Blob Tags Vorgang.

Wenn Tags nicht im x-ms-tags-Header bereitgestellt werden, werden sie nicht aus dem Quell-BLOB kopiert.

Verschlüsselungsbereiche und vom Kunden bereitgestellte Schlüssel

Die Put Blob From URL-API unterstützt sowohl Verschlüsselungsbereiche als auch vom Kunden bereitgestellte Schlüssel mithilfe der x-ms-encryption-scope bzw. x-ms-encryption-key Header.

Wenn sich der x-ms-copy-source-Header auf das gleiche Quell-Blob wie das Ziel-BLOB im Anforderungs-URI bezieht, führt der Put Blob From URL Vorgang eine synchrone direkte Neuschreibung des Blobs durch. Dies ermöglicht das Umschreiben eines Blobs, um einen anderen Verschlüsselungsschlüssel oder Verschlüsselungsbereich zu verwenden.

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. 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 Put Blob From URL Anforderungen basierend auf dem Speicherkontotyp:

Operation	Speicherkontotyp	Abrechnungskategorie
Blob von URL (Zielkonto¹)	Premium-Block-BLOB Standard general-purpose v2 Standard general-purpose v1	Schreibvorgänge
Blob von URL ablegen (Quellkonto²)	Premium-Block-BLOB Standard general-purpose v2 Standard general-purpose v1	Dient zum Lesen von Vorgängen.

¹Das Zielkonto wird für eine Transaktion belastet, um den Schreibvorgang zu initiieren.
²Das Quellkonto verursacht eine Transaktion für jede Leseanforderung an das Quellobjekt.

Wenn sich die Quell- und Zielkonten in verschiedenen Regionen (z. B. "USA Nord" und "USA Süd") befinden, wird die Bandbreite, die zum Übertragen der Anforderung verwendet wird, als Übergabe auf das Quellspeicherkonto belastet. Der Ausgang zwischen Konten innerhalb derselben Region ist kostenlos.

Zum Schluss verwendet das Erstellen eines neuen Blobs mit einem anderen Namen innerhalb desselben Speicherkontos zusätzliche Speicherressourcen, sodass der Vorgang zu einer Belastung für die Kapazitätsauslastung des Speicherkontos für diese zusätzlichen Ressourcen führt.

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

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage Status und Fehlercodes Blob-Dienstfehlercodes Festlegen von Timeouts für Blob-Dienstvorgänge

Freigeben über