VERTRIEB: 1-800-867-1380

Put Blob

Letzte Aktualisierung: Januar 2014

Der Put Blob-Vorgang erstellt ein neues Block-BLOB oder Seitenblob, oder er aktualisiert den Inhalt eines vorhandenen Block-BLOB.

Beim Aktualisieren eines vorhandenen Block-BLOB werden alle vorhandenen Metadaten im BLOB überschrieben. Teilweise Updates werden von Put Blob nicht unterstützt; der Inhalt des vorhandenen BLOB wird mit dem Inhalt des neuen BLOB überschrieben. Wenn ein teilweises Update des Inhalts eines Block-BLOB ausgeführt werden soll, verwenden Sie den Put Block List-Vorgang.

Beachten Sie, dass beim Aufrufen von Put Blob zum Erstellen eines Seitenblob das BLOB nur initialisiert wird. Rufen Sie den Put Page-Vorgang auf, um einem Seitenblob Inhalt hinzuzufügen.

Die Put Blob-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

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

HTTP/1.1

Beachten Sie, dass der Speicheremulator nur BLOB-Größen bis zu 2 GB unterstützt.

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

Im Anforderungs-URI können die folgenden zusätzlichen Parameter angegeben werden.

 

Parameter Beschreibung

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 die erforderlichen und optionalen Anforderungsheader bei Vorgängen für Block-BLOBs und Seitenblobs 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 der Anforderung.

Für ein Seitenblob muss der Wert dieses Headers auf 0 (null) festgelegt werden, da das Seitenblob mit Put Blob nur initialisiert wird. Die Größe des Seitenblobs wird im x-ms-blob-content-length-Header angegeben. Der gesamte Inhalt muss durch Aufrufen von Put Page in ein Seitenblob geschrieben werden.

Content-Type

Optional. Der MIME-Inhaltstyp des BLOB. 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 Get Blob-Vorgang für die BLOB-Ressource ausgeführt wird. Der Client kann mit diesem Rückgabewert den BLOB-Inhalt decodieren.

Content-Language

Optional. Gibt die natürlichen Sprachen an, die von dieser Ressource verwendet werden.

Content-MD5

Optional. Ein MD5-Hash des BLOB-Inhalts. Mithilfe des Hash wird die Integrität des BLOB während der Übertragung überprüft. Bei Angabe dieses Headers überprüft der Speicherdienst den Hash, der zusammen mit dem gesendeten eingegangen ist. Wenn die beiden Hashs nicht übereinstimmen, schlägt der Vorgang mit Fehlercode 400 (Ungültige Anforderung) fehl.

Wird er in Versionen ab 2012-02-12 nicht angegeben, generiert der Blob-Dienst einen MD5-Hash.

Ergebnisse von Get Blob, Get Blob Properties und List Blobs schließen den MD5-Hash ein.

Cache-Control

Optional. Dieser Wert wird vom Blob-Dienst gespeichert, jedoch nicht verwendet oder geändert.

x-ms-blob-content-type

Optional. Legt den Inhaltstyp des BLOB fest.

x-ms-blob-content-encoding

Optional. Legt die Inhaltscodierung des BLOB fest.

x-ms-blob-content-language

Optional. Legt die Sprache für den Inhalt des BLOB fest.

x-ms-blob-content-md5

Optional. Legt den MD5-Hash des BLOB fest.

x-ms-blob-cache-control

Optional. Legt das Cachesteuerelement des BLOB fest.

x-ms-blob-type:<BlockBlob | PageBlob>

Erforderlich. Gibt den Typ des zu erstellenden BLOBs an. Blockblob oder Seitenblob.

x-ms-meta-name:value

Optional. Name-Wert-Paare, die dem BLOB als Metadaten zugeordnet sind.

Beachten Sie, dass ab Version 2009-09-19 Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen müssen.

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-blob-content-disposition

Optional. Legt den Content-Disposition-Header des BLOBs fest. Dieser ist für die Version 2013-08-15 und höher verfügbar.

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 Parameter auf attachment festgelegt ist, bedeutet dies, dass der Benutzer-Agent nicht die Antwort, sondern stattdessen das Dialogfeld Speichern unter mit einem anderen Dateinamen als dem angegebenen BLOB-Namen anzeigen soll.

Die Antwort des Get Blob-Vorgangs und des Get Blob Properties-Vorgangs enthält den content-disposition-Header.

Origin

Optional. Gibt die Ursprungsdomäne an, von der die Anforderung ausgegeben wird. Wenn dieser Header vorhanden ist, werden CORS (Cross-Origin Resource Sharing)-Header für die Antwort erzeugt. Ausführliche Informationen finden Sie unter CORS (Cross-Origin Resource Sharing)-Unterstützung für Azure-Speicherdienste.

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.

Dieser Vorgang unterstützt zudem die Verwendung von bedingten Headern zum Schreiben in das BLOB nur dann, wenn eine bestimmte Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Vorgänge des Blob-Diensts.

In der folgenden Tabelle werden die Anforderungsheader beschrieben, die nur auf Vorgänge mit Seitenblobs anwendbar sind.

 

Anforderungsheader Beschreibung

x-ms-blob-content-length: bytes

Erforderlich für Seitenblobs. Dieser Header gibt die maximale Größe für das Seitenblob an, zulässig sind bis zu 1 TB. Die Größe des Seitenblobs muss auf eine Begrenzung von 512 Bytes ausgerichtet werden.

Wenn der Header für ein Block-BLOB angegeben wird, gibt der Blob-Dienst Statuscode 400 (Ungültige Anforderung) zurück.

x-ms-blob-sequence-number: <num>

Optional. Wird nur für Seitenblobs festgelegt. Die Sequenznummer ist ein vom Benutzer festgelegter Wert, anhand dessen Anforderungen nachverfolgt werden können. Der Wert der Sequenznummer muss zwischen 0 und 2^63 - 1 liegen. Der Standardwert ist 0.

Für ein Block-BLOB enthält der Anforderungstext den Inhalt des BLOB.

Für ein Seitenblob ist der Anforderungstext leer.

Im folgenden Beispiel wird eine Anforderung zum Erstellen eines Block-BLOB veranschaulicht:

Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblockblob HTTP/1.1
Request Headers:
x-ms-version: 2013-08-15
x-ms-date: Wed, 23 Oct 2013 22:33:355 GMT
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
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=
Content-Length: 11
Request Body:
hello world

Mit dieser Beispielanforderung wird ein Seitenblob erstellt, dessen maximale Größe als 1024 Bytes angegeben wird. Beachten Sie, dass Sie Put Page aufrufen müssen, um einem Seitenblob Inhalt hinzuzufügen:

Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/mypageblob HTTP/1.1
Request Headers:
x-ms-version: 2013-08-15
x-ms-date: Wed, 23 Oct 2013 22:41:55 GMT
Content-Type: text/plain; charset=UTF-8
x-ms-blob-type: PageBlob
x-ms-blob-content-length: 1024
x-ms-blob-sequence-number: 0
Authorization: SharedKey 
Origin: http://contoso.com
Vary: Origin
myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=
Content-Length: 0

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

ETag

Das ETag enthält einen Wert, den der Client zum Ausführen von bedingten PUT-Vorgängen mit dem If-Match-Anforderungsheader verwenden kann. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.

Last-Modified

Datum/Uhrzeit der letzten Änderung des BLOB. Das Datumsformat entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellung von Datums-/Uhrzeitwerten in Headern.

Bei jedem Schreibvorgang für das BLOB (einschließlich von Updates der Metadaten oder Eigenschaften des BLOB) wird der Zeitpunkt der letzten Änderung des BLOB geändert.

Content-MD5

Dieser Header wird für ein Block-BLOB zurückgegeben, sodass der Client die Integrität des Meldungsinhalts überprüfen kann. Der zurückgegebene Content-MD5-Wert wird vom Blob-Dienst berechnet. Ab Version 2012-02-12 wird dieser Header selbst dann zurückgegeben, wenn die Anforderung nicht den Content-MD5-Header oder den x-ms-blob-content-md5-Header enthält.

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.

Access-Control-Allow-Origin

Wird zurückgegeben, wenn die Anforderung einen Origin-Header enthält und CORS mit einer Abgleichsregel aktiviert ist. Dieser Header gibt den Wert des Origin-Anforderungsheaders im Falle einer Übereinstimmung zurück.

Access-Control-Expose-Headers

Wird zurückgegeben, wenn die Anforderung einen Origin-Header enthält und CORS mit einer Abgleichsregel aktiviert ist. Gibt die Liste der Antwortheader zurück, die gegenüber dem 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 Abgleichsregel aktiviert ist, die nicht alle Ursprungsdomänen zulässt. Dieser Header wird auf TRUE festgelegt.

Keiner.

Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==
Date: Wed, 23 Oct 2013 22:33:35 GMT
ETag: "0x8CB171BA9E94B0B"
Last-Modified: Wed, 23 Oct 2013 22:30:15 GMT
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

Dieser Vorgang kann vom Kontobesitzer und von einem beliebigen Client mit einer SAS aufgerufen werden, der über die Berechtigung verfügt, in dieses BLOB bzw. dessen Container zu schreiben.

Beim Erstellen eines BLOB müssen Sie angeben, ob ein Block-BLOB oder ein Seitenblob erstellt werden soll. Sobald ein BLOB erstellt wurde, kann der Typ des BLOB nicht mehr geändert werden, es sei denn, das BLOB wird gelöscht und neu erstellt.

Zum Erstellen eines neuen Seitenblobs initialisieren Sie zunächst das BLOB, indem Sie Put Blob aufrufen und seine maximale Größe (bis zu 1 TB) angeben. Beim Erstellen eines Seitenblob darf kein Inhalt in den Anforderungstext eingeschlossen werden. Rufen Sie nach dem Erstellen des BLOB Put Page auf, um dem BLOB Inhalt hinzuzufügen oder um das BLOB zu ändern.

Die maximale Uploadgröße für ein Block-BLOB beträgt 64 MB. Wenn das BLOB größer als 64 MB ist, müssen Sie es als Gruppe von Blöcken hochladen. Weitere Informationen finden Sie unter dem Put Block-Vorgang und dem Put Block List-Vorgang. Wenn das BLOB als Gruppe von Blöcken hochgeladen wird, muss Put Blob nicht aufgerufen werden.

Wenn Sie versuchen, ein Block-BLOB mit einer Größe von mehr als 64 MB oder ein Seitenblob mit einer Größe von mehr als 1 TB hochzuladen, gibt der Dienst Statuscode 413 (Anforderungsentität ist zu groß) zurück. Der Blob-Dienst gibt in der Antwort zudem weitere Informationen zum Fehler zurück, einschließlich der maximal zulässigen BLOB-Größe in Bytes.

Wenn Sie Put Blob aufrufen, um ein vorhandenes BLOB mit demselben Namen zu überschreiben, werden alle Momentaufnahmen beibehalten, die dem ursprünglichen BLOB zugeordnet sind. Rufen Sie zum Entfernen zugehöriger Momentaufnahmen zuerst BLOB löschen auf, und rufen Sie anschließend Put Blob auf, um das BLOB neu zu erstellen.

Ein BLOB enthält (über Header festgelegte) benutzerdefinierte Eigenschaften, mit denen Sie Werte speichern können, die HTTP-Standardheadern zugeordnet sind. Diese Werte können anschließend durch einen Aufruf von Get Blob Properties gelesen oder durch einen Aufruf von Festlegen von BLOB-Eigenschaften geändert werden. Die Header mit benutzerdefinierten Eigenschaften und der entsprechende HTTP-Standardheader werden in der folgenden Tabelle aufgelistet:

 

HTTP-Header Header mit benutzerdefinierten BLOB-Eigenschaften

Content-Type

x-ms-blob-content-type

Content-Encoding

x-ms-blob-content-encoding

Content-Language

x-ms-blob-content-language

Content-MD5

x-ms-blob-content-md5

Cache-Control

x-ms-blob-cache-control

Beim Festlegen, dass diese Eigenschaftenwerte mit dem BLOB permanent gespeichert werden, gilt die folgende Semantik:

  • Wenn der Client einen Header mit benutzerdefinierten Eigenschaften angibt (wie durch das x-ms-blob-Präfix angezeigt), wird dieser Wert mit dem BLOB gespeichert.

  • Wenn der Client einen HTTP-Standardheader, jedoch nicht den Header mit benutzerdefinierten Eigenschaften angibt, wird der Wert in der entsprechenden benutzerdefinierten Eigenschaft gespeichert, die dem BLOB zugeordnet ist; der Wert wird durch einen Aufruf von Get Blob Properties zurückgegeben. Wenn der Client den Content-Type-Header für die Anforderung festlegt, wird dieser Wert in der x-ms-blob-content-type-Eigenschaft des BLOB gespeichert.

  • Wenn der Client den HTTP-Standardheader und den entsprechenden Eigenschaftenheader für dieselbe Anforderung festlegt, verwendet die PUT-Anforderung den für den HTTP-Standardheader angegebenen Wert, der angegebene Wert für den Header mit benutzerdefinierten Eigenschaften wird hingegen mit dem BLOB dauerhaft gespeichert und durch nachfolgende GET-Anforderungen zurückgegeben.

Wenn das BLOB über eine aktive Lease verfügt, muss der Client zum Überschreiben des BLOB eine gültige Lease-ID in der Anforderung 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. Wenn der Client eine Lease-ID für ein BLOB angibt, das noch nicht vorhanden ist, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) für Anforderungen zurück, die für Version 2013-08-15 und höher ausgeführt werden; für frühere Versionen gibt der Blob-Dienst den Statuscode 201 (Erstellt) zurück.

Wenn ein vorhandenes BLOB mit einer aktiven Lease durch einen Put Blob-Vorgang überschrieben wird, wird die Lease im aktualisierten BLOB permanent gespeichert, bis sie abläuft oder freigegeben wird.

Für einen Put Blob-Vorgang ist eine Dauer von 10 Minuten pro MB bis zum Abschluss zulässig. Wenn der Vorgang länger als durchschnittlich 10 Minuten pro MB dauert, tritt ein Timeout des Vorgangs auf.

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