Freigeben über

Put Block From URL

  • Artikel

Der Put Block From URL Vorgang erstellt einen neuen Block, der als Teil eines Blobs committet werden soll, in dem der Inhalt aus einer URL gelesen wird. Diese API ist ab Version 2018-03-28 verfügbar.

Anforderung

Sie können die Put Block From URL Anforderung 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?comp=block&blockid=id HTTP/1.1

Emulierte Speicherdienstanforderung

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und den Blobdienstport als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

PUT-Methodenanforderungs-URI HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id HTTP/1.1

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

URI-Parameter

Parameter BESCHREIBUNG
blockid Erforderlich. Ein gültiger Base64-Zeichenfolgenwert, der den Block bezeichnet. Vor der Codierung muss die Zeichenfolge kleiner oder gleich 64 Bytes sein.

Für ein angegebenes Blob muss die Länge des angegebenen Werts für den blockid Parameter die gleiche Größe für jeden Block haben.

Hinweis: Die Base64-Zeichenfolge muss URL-codiert sein.
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blobdienstvorgä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 (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. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste. Für Put Block From URLmuss die Version 2018-03-28 oder höher sein.
Content-Length Erforderlich. Gibt die Anzahl der Bytes an, die im Anforderungstext übertragen werden. Der Wert dieses Headers muss auf 0 festgelegt werden. Wenn die Länge nicht 0 ist, schlägt der Vorgang mit status Code 400 (Ungültige Anforderung) fehl.
x-ms-copy-source:name Erforderlich. Gibt die URL des Quellblobs an. Der Wert kann eine URL mit einer Länge 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 Quellblob muss entweder öffentlich oder über eine Freigegebene Zugriffssignatur autorisiert sein. Wenn das Quellblob öffentlich ist, ist zum Ausführen des Vorgangs keine Autorisierung erforderlich. 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.
Nur ein Trägerschema wird für Microsoft Entra unterstützt.
Dieser Header wird in den Versionen 2020-10-02 und höher unterstützt.
x-ms-source-range Optional. Lädt nur die Bytes des Blobs in die Quell-URL im angegebenen Bereich hoch. Wenn dieser Header nicht angegeben wird, wird der gesamte Quellblobinhalt als einzelner Block hochgeladen. Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blobdienstvorgänge.
x-ms-source-content-md5 Optional. Ein MD5-Hash des Blockinhalts aus dem URI. Dieser Hash wird verwendet, um die Integrität des Blocks beim Transport der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der aus der Copy-Source-Quelle eingegangen ist, mit diesem Headerwert.

Hinweis: Dieser MD5-Hash wird nicht mit dem Blob gespeichert.

Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.
x-ms-source-content-crc64 Optional. Ein CRC64-Hash des Blockinhalts aus dem URI. Dieser Hash wird verwendet, um die Integrität des Blocks beim Transport der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der aus der Copy-Source-Quelle eingegangen ist, mit diesem Headerwert.

Hinweis: Dieser CRC64-Hash wird nicht mit dem Blob gespeichert.

Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Wenn sowohl als x-ms-source-content-crc64 auch x-ms-source-content-md5 Header vorhanden sind, schlägt die Anforderung mit einer 400 (ungültige Anforderung) fehl.

Dieser Header wird in Versionen 2019-02-02 und höher unterstützt.
x-ms-encryption-scope Optional. Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Quellinhalts verwendet werden soll. Dieser Header wird in Versionen 2019-02-02 und höher unterstützt.
x-ms-lease-id:<ID> Erforderlich, wenn das BLOB über eine aktive Lease verfügt. Um diesen Vorgang für ein BLOB mit einer aktiven Lease auszuführen, geben Sie die gültige Lease-ID für diesen Header an.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen Azure Blob Storage.

Anforderungsheader (vom Kunden bereitgestellte Verschlüsselungsschlüssel)

Ab Version 2019-02-02 können die folgenden Header für die Anforderung zum Verschlüsseln eines Blobs mit einem vom Kunden bereitgestellten Schlüssel angegeben werden. Die Verschlüsselung mit einem vom Kunden bereitgestellten Schlüssel (und der entsprechenden Gruppe 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 dieses Headers muss auf AES256 festgelegt sein.

Anforderungstext

Keine.

Beispiel für eine Anforderung

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

Antwort

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

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben.

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

Antwortheader

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

Antwortheader BESCHREIBUNG
Content-MD5 Wird zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Der Wert dieses Headers wird von Blob Storage berechnet. Er ist nicht unbedingt identisch mit dem Wert, der in den Anforderungsheadern angegeben wird. Für Versionen 2019-02-02 und höher wird dieser Header nur zurückgegeben, wenn die Anforderung über diesen Header verfügt.
x-ms-content-crc64 Für Versionen 2019-02-02 und höher. Wird zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Der Wert dieses Headers wird von Blob Storage berechnet. Es ist nicht notwendigerweise identisch mit dem Wert, der in den Anforderungsheadern angegeben wird.

Wird zurückgegeben, wenn x-ms-source-content-md5 der Header in der Anforderung nicht vorhanden ist.
x-ms-request-id Identifiziert die durchgeführte Anforderung eindeutig, und Sie können sie zur Problembehandlung für die Anforderung verwenden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Die Blob Storage-Version, die zum Ausführen der Anforderung verwendet wurde.
Date Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde.
x-ms-request-server-encrypted: true/false Version 2015-12-11 und höher. Der Wert dieses Headers wird auf true festgelegt, wenn der Inhalt des Blocks mit dem angegebenen Algorithmus erfolgreich verschlüsselt wurde. Andernfalls wird der Wert auf false festgelegt.
x-ms-encryption-key-sha256 Version 2019-02-02 und höher. Wird zurückgegeben, wenn die Anforderung einen vom Kunden bereitgestellten Schlüssel für die Verschlüsselung verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des bereitgestellten Schlüssels erfolgreich verschlüsselt wurde.
x-ms-encryption-scope Version 2019-02-02 und höher. Wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, sodass der Client sicherstellen kann, dass der Inhalt der Anforderung mithilfe des Verschlüsselungsbereichs erfolgreich verschlüsselt wurde.
x-ms-client-request-id Kann zur Problembehandlung von Anforderungen und entsprechenden Antworten verwendet werden. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Put Block From URL Vorgang wie unten beschrieben autorisieren.

Wichtig

Microsoft empfiehlt die Verwendung von 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 eine höhere Sicherheit und Benutzerfreundlichkeit.

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

Put Block From URL lädt einen Block hoch, der später in einen Block-BLOB eingeschlossen werden soll. Ein Blockblob kann maximal 50.000 Blöcke enthalten. Jeder Block kann eine andere Größe haben. Die maximale Größe für einen Block, der mit Put Block From URL hochgeladen wird, beträgt 100 Mebibytes (MiB). Informationen zum Hochladen größerer Blöcke (bis zu 4.000 MiB) finden Sie unter Put Block.

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

Ein Blob kann jederzeit maximal 100.000 Blöcke ohne Commit enthalten. Wenn dieses Maximum überschritten wird, gibt der Dienst status Code 409 (RequestEntityTooLargeBlockCountExceedsLimit) zurück.

In der folgenden Tabelle werden die maximal zulässigen Block- und Blobgrößen nach Dienstversion beschrieben:

Dienstversion Maximale Blockgröße (über Put Block From URL) Maximale Blobgröße (über Put Block List) Maximale Blobgröße über einen einzelnen Schreibvorgang (über Put Blob From URL)
Version 2020-04-08 und höher 4.000 MiB Ungefähr 190,7 Tebibyte (TiB) (4.000 MiB × 50.000 Blöcke) 5.000 MiB
Versionen vor dem 08.04.2020 100 MiB Ungefähr 4,75 TiB (100 MiB × 50.000 Blöcke) 256 MiB

Nachdem Sie eine Reihe von Blöcken hochgeladen haben, können Sie das Blob auf dem Server aus dieser Gruppe erstellen oder aktualisieren, indem Sie den Vorgang Put Block List aufrufen. Jeder Block im Satz wird durch eine Block-ID identifiziert, die innerhalb dieses Blobs eindeutig ist. Block-IDs werden als Bereich zu einem bestimmten BLOB zusammengefasst, sodass verschiedene BLOBs Blöcke mit gleichen IDs enthalten können.

Wenn Sie ein Blob aufrufen Put Block From URL , das noch nicht vorhanden ist, wird ein neues Blockblob mit einer Inhaltslänge von 0 erstellt. Wenn die include=uncommittedblobs-Option angegeben wurde, wird das BLOB mit dem Vorgang List Blobs aufgelistet. Für den Block oder die Blöcke, die Sie hochgeladen haben, wird erst dann ein Commit ausgeführt, wenn Sie Put Block List für das neue BLOB aufrufen. Ein auf diese Weise erstelltes Blob wird eine Woche lang auf dem Server verwaltet. Wenn Sie innerhalb dieses Zeitraums keine weiteren Blöcke oder Commits für das Blob hinzugefügt haben, wird das Blob mit Müll gesammelt.

Ein Block, der mit dem Put Block From URL Vorgang erfolgreich hochgeladen wurde, wird erst Dann Teil eines Blobs, wenn er mit Put Block Listcommittet wird. Bevor Put Block List aufgerufen wird, um das neue oder aktualisierte Blob zu commiten, geben alle Aufrufe von Get Blob den Blobinhalt zurück, ohne den nicht festgeschriebenen Block einzubeziehen.

Wenn Sie einen Block hochladen, der die gleiche Block-ID wie ein anderer Block aufweist, der noch nicht committet wurde, wird der letzte hochgeladene Block mit dieser ID beim nächsten erfolgreichen Put Block List Vorgang committet.

Nachdem Put Block List aufgerufen wurde, wird für in der Blockliste angegeben Blöcke ohne ausgeführtes Commit ein Commit als Teil des neuen BLOB ausgeführt. Alle nicht belegten Blöcke, die nicht in der Blockliste für das Blob angegeben wurden, werden gesammelt und aus Blob Storage entfernt. Alle nicht freigegebenen Blöcke werden ebenfalls mit Müll gesammelt, wenn innerhalb einer Woche nach dem letzten erfolgreichen Put Block From URL Vorgang keine erfolgreichen Aufrufe Put Block From URL für oder Put Block List für dasselbe Blob ausgeführt werden. Wenn Put Blob für das Blob aufgerufen wird, werden alle nicht freigegebenen Blöcke mit Müll gesammelt.

Wenn das Blob über eine aktive Lease verfügt, muss der Client eine gültige Lease-ID für die Anforderung angeben, um einen Block in das Blob zu schreiben. Wenn der Client entweder keine Lease-ID oder eine ungültige Lease-ID angibt, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Wenn der Client eine Lease-ID angibt, das Blob jedoch nicht über eine aktive Lease verfügt, gibt Blob Storage auch status Code 412 (Vorbedingung fehlgeschlagen) zurück.

Für ein angegebenes Blob müssen alle Block-IDs die gleiche Länge aufweisen. Wenn ein Block mit einer Block-ID hochgeladen wird, die sich von der der Block-IDs für vorhandene nicht festgelegte Blöcke unterscheidet, gibt der Dienst den Fehlerantwortcode 400 (Ungültige Anforderung) zurück.

Beim Aufrufen Put Block From URL wird der Zeitpunkt der letzten Änderung eines vorhandenen Blobs nicht aktualisiert.

Beim Aufruf von Put Block From URL für ein Seiten-BLOB wird ein Fehler zurückgegeben.

Das Aufrufen Put Block From URL eines Archivblobs gibt einen Fehler zurück, und das Aufrufen eines hot Blobs oder cool ändert die Blobebene nicht.

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

Vorgang Speicherkontotyp Abrechnungskategorie
Put Block From URL (Zielkonto1) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Schreibvorgänge
Put Block From URL (Quellkonto2) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Dient zum Lesen von Vorgängen.

1Das Zielkonto wird für eine Transaktion in Rechnung gestellt, 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 befinden (z. B. USA, Norden und USA, Süden), wird außerdem die Bandbreite, die für die Übertragung der Anforderung verwendet wird, dem Quellspeicherkonto als Ausgehender Wert in Rechnung gestellt. Der Ausgang zwischen Konten innerhalb derselben Region ist kostenlos.

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

Weitere Informationen