Freigeben über

Blob von URL ablegen

  • Artikel

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 BlockBlobsein muss. Wenn der BLOB-Typ nicht BlockBlobist, 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-tagsangegeben 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 Truewerden 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-Matchangegebenen 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 attachmentfestgelegt 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, Coldund Archive. Hinweis: Cold Stufe wird für Version 2021-12-02 und höher unterstützt. Hot, Coolund 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 AES256sein.

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 truefestgelegt.
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 falsefestgelegt.
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:

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

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 (Zielkonto1) Premium-Block-BLOB
Standard general-purpose v2
Standard general-purpose v1		 Schreibvorgänge
Blob von URL ablegen (Quellkonto2) Premium-Block-BLOB
Standard general-purpose v2
Standard general-purpose v1		 Dient zum Lesen von Vorgängen.

1Das Zielkonto wird für eine Transaktion belastet, um den Schreibvorgang zu initiieren.
2Das 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 StorageStatus und FehlercodesBlob-DienstfehlercodesFestlegen von Timeouts für Blob-Dienstvorgänge