VERTRIEB: 1-800-867-1380

Put Block

Letzte Aktualisierung: Februar 2014

Mit dem Vorgang Put Block wird ein neuer Block erstellt, für den ein Commit als Teil eines BLOB ausgeführt werden soll.

Die Put Block-Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

 

  Anforderungs-URI für PUT-Methode HTTP-Version

https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id

HTTP/1.1

Wenn Sie eine Anforderung für den emulierten Speicherdienst ausführen, geben Sie den Emulatorhostnamen und den Port des Blob-Diensts mit 127.0.0.1:10000 an, gefolgt vom Namen des emulierten Speicherkontos:

 

  Anforderungs-URI für PUT-Methode HTTP-Version

http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id

HTTP/1.1

Weitere Informationen finden Sie unter Einsatz des Azure-Speicheremulators für Entwicklung und Tests.

 

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 jedes BLOB muss die Länge des für den blockid-Parameter angegebenen Werts gleich der Größe jedes Blocks sein.

Beachten Sie, dass die Base64-Zeichenfolge codiert sein muss.

timeout

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

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

 

Anforderungsheader Beschreibung

Authorization

Erforderlich. Gibt das Authentifizierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

Date - oder - x-ms-date

Erforderlich. Gibt die Uhrzeit der Anforderung in koordinierter Weltzeit (UTC) an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

x-ms-version

Erforderlich für alle authentifizierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.

Content-Length

Erforderlich. Die Länge des Blockinhalts in Bytes. Der Block muss kleiner oder gleich 4 MB sein.

Wenn die Länge nicht angegeben ist, tritt bei dem Vorgang ein Fehler mit dem Statuscode 411 (Länge erforderlich) auf.

Content-MD5

Optional. Ein MD5-Hash des Blockinhalts. Mithilfe des Hashs wird die Integrität des Blocks während der Übertragung überprüft. Bei Angabe dieses Headers vergleicht der Speicherdienst den Hash des eingegangenen Inhalts mit diesem Headerwert.

Beachten Sie, dass dieser MD5-Hash nicht mit dem BLOB gespeichert wird.

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

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, nicht transparenten Wert mit einer Zeichenbeschränkung von 1 KB bereit, der in den Analyseprotokollen erfasst wird, wenn die Protokollierung der Speicheranalyse aktiviert ist. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit den vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Informationen zur Protokollierung durch die Speicheranalyse und Windows Azure-Protokollierung: Verwenden von Protokollen zur Nachverfolgung von Speicheranforderungen.

Der Anforderungstext enthält den Inhalt des Blocks.

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: 2011-08-18
x-ms-date: Sun, 25 Sep 2011 14:37:35 GMT
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=
Content-Length: 1048576

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

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

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

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

Dieser Header wird zurückgegeben, damit der Client die Integrität des Nachrichteninhalts überprüfen kann. Der Wert dieses Headers wird vom Blob-Dienst berechnet; er stimmt nicht unbedingt mit dem Wert überein, der in den Anforderungsheadern angegeben wurde.

x-ms-request-id

Dieser Header identifiziert die erfolgte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.

x-ms-version

Gibt die Version des Blob-Diensts an, der zum Ausführen der Abfrage verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.

Date

Ein vom Dienst generierter Datums-/Uhrzeitwert in UTC, der angibt, wann die Antwort initiiert wurde.

Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
Content-MD5: BN3lsXf+t19nMGs+vYakPA==
Date: Sun, 25 Sep 2011 23:47:09 GMT
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Dieser Vorgang kann vom Kontobesitzer und von einem Benutzer mit einer SAS (Shared Access Signature) aufgerufen werden, der über die Berechtigung verfügt, in dieses BLOB oder den Container zu schreiben.

Put Block lädt einen Block hoch, der später in einen Block-BLOB eingeschlossen werden soll. Ein Block kann bis zu 4 MB groß sein.

Wenn Sie einen Satz von Blöcken hochgeladen haben, können Sie das BLOB auf dem Server anhand dieses Satzes erstellen oder aktualisieren, indem Sie den Vorgang Put Block List aufrufen. Jeder Satz im Block wird durch eine Block-ID bezeichnet, die innerhalb des BLOB 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 Put Block für ein BLOB aufrufen, das noch nicht vorhanden ist, wird ein neues Blockblob mit der Inhaltslänge 0 erstellt. Wenn die include=uncommittedblobs-Option angegeben wurde, wird das BLOB mit dem List Blobs-Vorgang 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 dem BLOB innerhalb dieses Zeitraums keine Blöcke oder Blöcke mit ausgeführtem Commit hinzufügen, unterliegt das BLOB der Garbage Collection.

Die maximale derzeit vom Vorgang Put Block List unterstützte BLOB-Größe beträgt 200 GB und bis zu 50.000 Blöcke. Ein BLOB kann immer maximal 100.000 Blöcken ohne ausgeführtes Commit enthalten, und die Blöcke ohne ausgeführtes Commit dürfen eine Gesamtgröße von 400 GB nicht überschreiten. Wenn diese Maximalwerte überschritten werden, gibt der Dienst den Statuscode 413 zurück (RequestEntityTooLarge).

Der Block, der mit dem Vorgang Put Block erfolgreich hochgeladen wurde, wird erst Teil eines BLOB, wenn für ihn mit Put Block List ein Commit ausgeführt wurde. Bevor Put Block List aufgerufen wird, um ein Commit für das neue oder aktualisierte BLOB auszuführen, geben alle Aufrufe von Get Blob den BLOB-Inhalt ohne die Blöcke ohne ausgeführtes Commit zurück.

Wenn Sie einen Block hochladen, der die gleiche Block-ID wie ein anderer Block besitzt, für den noch kein Commit ausgeführt wurde, wird beim nächsten erfolgreichen Put Block List-Vorgang ein Commit für den zuletzt hochgeladenen Block mit dieser ID ausgeführt.

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 Blöcke, für die kein Commit ausgeführt wurde und die nicht in der Blockliste für das BLOB angegeben sind, unterliegen der Garbage Collection und werden aus dem Blob-Dienst entfernt. Alle Blöcke ohne ausgeführten Commit werden ebenfalls vom Garbage Collector erfasst, wenn für dieses BLOB innerhalb einer Woche nach dem letzten erfolgreichen Put Block-Vorgang keine erfolgreichen Aufrufe von Put Block List oder Put Block erfolgen. Wenn Put Blob für das BLOB aufgerufen wird, werden alle Blöcke ohne ausgeführten Commit vom Garbage Collector erfasst.

Wenn das BLOB über eine aktive Lease verfügt, muss der Client zum Schreiben eines Blocks in das BLOB in der Anforderung eine gültige Lease-ID angeben. Wenn der Client keine Lease-ID oder eine ungültige Lease-ID angibt, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) zurück. Wenn der Client eine Lease-ID angibt, aber das BLOB nicht über eine aktive Lease verfügt, gibt der Blob-Dienst ebenfalls Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

In einem bestimmten BLOB müssen alle Block-IDs dieselbe Länge aufweisen. Wenn ein Block mit einer Block-ID einer anderen Länge hochgeladen wird, als die Block-IDs für vorhandene Blöcke ohne ausgeführten Commit aufweisen, gibt der Dienst den Fehlerantwortcode 400 zurück (ungültige Anforderung).

Wenn Sie versuchen, einen größeren Block als 4 MB hochzuladen, gibt der Dienst Statuscode 413 zurück (Anforderungsentität zu groß). Der Dienst gibt in der Antwort zudem weitere Informationen zum Fehler zurück, einschließlich der maximal zulässigen Blockgröße in Bytes.

Beim Aufrufen von Put Block wird die Uhrzeit der letzten Änderung eines vorhandenen BLOB nicht aktualisiert.

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

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2015 Microsoft