(0) exportieren Drucken
Alle erweitern

Put Page

Letzte Aktualisierung: Januar 2014

Der Put Page-Vorgang schreibt einen Bereich von Seiten in ein Seitenblob.

Die Put Page-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=page

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=page

HTTP/1.1

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 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.

Range

Entweder Range oder x-ms-range ist erforderlich.

Gibt den Bereich von Bytes an, der als Seite geschrieben werden soll. Sowohl der Anfang als auch das Ende des Bereichs müssen angegeben werden. Dieser Header wird durch die HTTP/1.1-Protokollspezifikation definiert.

Für einen Seitenupdatevorgang kann die Größe des Seitenbereichs bis zu 4 MB betragen. Für einen Seitenlöschvorgang kann die Größe des Seitenbereichs dem Wert der Gesamtgröße des BLOB entsprechen.

Da Seiten an 512-Byte-Grenzen ausgerichtet sein müssen, muss der Anfangsoffset ein Restwert von 512 und der Endoffset ein Restwert von 512 – 1 sein. Beispiele für gültige Bytebereiche sind 0-511, 512-1023 usw.

Der BLOB-Dienst akzeptiert nur einen einzigen Bytebereich für den Range-Header, und der Bytebereich muss im folgenden Format angegeben werden: bytes=startByte-endByte.

Wenn Range und x-ms-range angegeben werden, verwendet der Dienst den Wert x-ms-range. Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blob-Dienstvorgänge.

x-ms-range

Entweder Range oder x-ms-range ist erforderlich.

Gibt den Bereich von Bytes an, der als Seite geschrieben werden soll. Sowohl der Anfang als auch das Ende des Bereichs müssen angegeben werden. Dieser Header wird durch die HTTP/1.1-Protokollspezifikation definiert.

Für einen Seitenupdatevorgang kann die Größe des Seitenbereichs bis zu 4 MB betragen. Für einen Seitenlöschvorgang kann die Größe des Seitenbereichs dem Wert der Gesamtgröße des BLOB entsprechen.

Da Seiten an 512-Byte-Grenzen ausgerichtet sein müssen, muss der Anfangsoffset ein Restwert von 512 und der Endoffset ein Restwert von 512 – 1 sein. Beispiele für gültige Bytebereiche sind 0-511, 512-1023 usw.

Der BLOB-Dienst akzeptiert nur einen einzigen Bytebereich für den x-ms-range-Header, und der Bytebereich muss im folgenden Format angegeben werden: bytes=startByte-endByte.

Wenn Range und x-ms-range angegeben werden, verwendet der Dienst den Wert x-ms-range. Weitere Informationen finden Sie unter Angeben des Bereichsheaders für Blob-Dienstvorgänge.

Content-Length

Erforderlich. Gibt die Anzahl der Bytes an, die im Anforderungstext übertragen werden. Wenn der x-ms-page-write-Header auf clear festgelegt ist, muss der Wert dieses Headers auf 0 (null) festgelegt werden.

Content-MD5

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

Der Content-MD5-Header ist nicht zulässig, wenn der x-ms-page-write-Header auf clear festgelegt ist. Wenn er in der Anforderung enthalten ist, gibt der Blob-Dienst Statuscode 400 (Ungültige Anforderung) zurück.

x-ms-page-write: {update | clear}

Erforderlich. Sie können eine der folgenden Optionen angeben:

  • Update: Schreibt die vom Anforderungstext angegebenen Bytes in den angegebenen Bereich. Der Range-Header und der Content-Length-Header müssen übereinstimmen, damit das Update ausgeführt werden kann.

  • Clear: Löscht den angegebenen Bereich und gibt den Platz im Speicher frei, der von diesem Bereich belegt wird. Legen Sie zum Löschen eines Bereichs den Content-Length-Header auf 0 (null) und den Header Range auf einen Wert fest, der den zu löschenden Bereich (bis zur maximalen BLOB-Größe) angibt.

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-if-sequence-number-le: <num>

Optional. Wenn die Sequenznummer des BLOB kleiner als oder gleich dem angegebenen Wert ist, wird die Anforderung fortgesetzt; andernfalls schlägt sie mit dem SequenceNumberConditionNotMet-Fehler (HTTP-Statuscode 412 - Vorbedingung nicht erfüllt) fehl.

x-ms-if-sequence-number-lt: <num>

Optional. Wenn die Sequenznummer des BLOB kleiner als der angegebene Wert ist, wird die Anforderung fortgesetzt; andernfalls schlägt sie mit dem SequenceNumberConditionNotMet-Fehler (HTTP-Statuscode 412 - Vorbedingung nicht erfüllt) fehl.

x-ms-if-sequence-number-eq: <num>

Optional. Wenn die Sequenznummer des BLOB gleich dem angegebenen Wert ist, wird die Anforderung fortgesetzt; andernfalls schlägt sie mit dem SequenceNumberConditionNotMet-Fehler (HTTP-Statuscode 412 - Vorbedingung nicht erfüllt) fehl.

If-Modified-Since

Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn das BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit geändert wurde. Wenn das BLOB nicht geändert wurde, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

If-Unmodified-Since

Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn das BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit nicht geändert wurde. Wenn das BLOB geändert wurde, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

If-Match

Optional. Ein ETag-Wert. Geben Sie einen ETag-Wert für diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn der ETag-Wert des BLOB dem angegebenen Wert entspricht. Bei nicht übereinstimmenden Werten gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

If-None-Match

Optional. Ein ETag-Wert.

Geben Sie einen ETag-Wert für diesen bedingten Header an, um die Seite nur dann zu schreiben, wenn der ETag-Wert des BLOB nicht dem angegebenen Wert entspricht. Bei übereinstimmenden Werten gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

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 Ausführen des Vorgangs, wobei eine bestimmte Bedingung erfüllt sein muss. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Vorgänge des Blob-Diensts.

Der Anforderungstext enthält den Inhalt der Seite.


Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1
Request Headers:
x-ms-page-write: update
x-ms-date: Fri, 16 Sep 2011 22:15:50 GMT
x-ms-version: 2011-08-18
x-ms-range: bytes=0-65535
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=
Content-Length: 65536


Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1
Request Headers:
Range: bytes=1024-2048
x-ms-page-write: clear
x-ms-date: Sun, 25 Sep 2011 23:37:35 GMT
x-ms-version: 2011-08-18
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=

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.

 

Syntax Beschreibung

ETag

Das ETag für das BLOB. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen. Das ETag kann verwendet werden, um einen bedingten Put Page-Vorgang auszuführen, indem sein Wert für den If-Match-Anforderungsheader oder den If-None-Match-Anforderungsheader angegeben wird.

Last-Modified

Das Datum und die 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 oder Eigenschaften, wird der Zeitpunkt der letzten Änderung des BLOB geändert.

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-blob-sequence-number

Die aktuelle Sequenznummer für das Seitenblob.

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.

Keiner.

Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==
Date: Sun, 25 Sep 2011 22:33:35 GMT
ETag: "0x8CB171BA9E94B0B"
Last-Modified: Sun, 25 Sep 2011 12:13:31 GMT
x-ms-version: 2011-08-18
x-ms-blob-sequence-number: 0
Content-Length: 0
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.

Der Put Page-Vorgang schreibt einen Bereich von Seiten in ein Seitenblob. Dieser Vorgang kann nur für ein vorhandenes Seitenblob aufgerufen werden. Er kann nicht aufgerufen werden, um ein neues Seitenblob erstellen, und er kann nicht für ein Block-BLOB aufgerufen werden. Bei einem Aufruf von Put Page mit dem Namen eines BLOB, das derzeit nicht vorhanden ist, wird der BlobNotFound-Fehler (HTTP-Statuscode 404 – Nicht gefunden) zurückgegeben.

Rufen Sie zum Erstellen eines neuen Seitenblobs Put Blob auf, und geben Sie an, dass das zu erstellende BLOB vom Typ Seitenblob sein soll. Ein Seitenblob kann eine Größe von bis zu 1 TB aufweisen.

Wenn das BLOB über eine aktive Lease verfügt, muss der Client zum Schreiben einer Seite eine gültige Lease-ID in der Anforderung angeben.

Seitenupdatevorgänge

Wenn Put Page mit der Option Update aufgerufen wird, wird ein direkter Schreibvorgang in das angegebene Seitenblob ausgeführt. Sämtlicher Inhalt der angegebenen Seite wird durch das Update überschrieben.

ImportantWichtig
Wenn während eines Put Page-Vorgangs ein Servertimeout auftritt oder die Verbindung geschlossen wird, wurde die Seite möglicherweise nicht aktualisiert. Daher sollten Sie mit einer Wiederholung des Updatevorgangs fortfahren, bis Sie eine Antwort mit einer Erfolgsmeldung empfangen.

Jeder Seitenbereich, der mit Put Page für einen Updatevorgang gesendet wird, kann eine Größe von bis zu 4 MB aufweisen. Der Start- und Endbereich der Seite muss an 512-Bytes-Begrenzungen ausgerichtet werden. Wenn Sie versuchen, einen Seitenbereich hochzuladen, dessen Größe 4 MB überschreitet, gibt der Dienst Statuscode 413 (Anforderungsentität ist zu groß) zurück.

Seitenlöschvorgänge

Beim Aufrufen von Put Page mit der Clear-Option wird der von der angegebenen Seite genutzte Speicherplatz freigegeben. Seiten, die gelöscht wurden, werden nicht mehr als Teil des Seitenblobs nachverfolgt.

Für gelöschte Seiten werden im Speicherkonto keine weiteren Gebühren berechnet, da ihre Speicherressourcen freigegeben wurden. Eine Ausnahme hiervon liegt vor, wenn bereits Momentaufnahmen des Seitenblobs vorhanden sind; für Seiten in Momentaufnahmen werden auch dann Gebühren berechnet, wenn die entsprechenden Seiten nicht mehr Bestandteil des Quell-BLOB sind.

Verwalten von Parallelitätsproblemen

er BLOB-Dienst verarbeitet parallele Schreibvorgänge in überlappenden Seiten sequenziell: Die letzte vom Dienst verarbeitete Seite bestimmt den Inhalt des BLOBs. Um die Integrität des Inhalts des BLOB sicherzustellen, sollte der Client beim Verarbeiten von Schreibvorgängen in überlappende Seiten einen oder mehrere der folgenden Ansätze verfolgen:

  • Sie können den Wert des Last-Modified-Antwortheaders für jeden erfolgreichen Aufruf von Put Page überprüfen. Die Reihenfolge der vom Blob-Dienst zurückgegebenen Antworten entspricht nicht unbedingt der Reihenfolge, in der die Anforderungen vom Dienst ausgeführt wurden. Der Wert von Last-Modified gibt jedoch immer die Reihenfolge an, in der die Anforderungen vom Dienst verarbeitet wurden.

  • Sie können Updates bedingt auf der Grundlage des ETags des BLOB oder des letzten Änderungszeitpunkts mit vollständiger Parallelität ausführen. Dieser Ansatz empfiehlt sich insbesondere dann, wenn die Anzahl gleichzeitiger Schreibvorgänge relativ gering ist. Verwenden Sie zu diesem Zweck die bedingten Anforderungsheader If-Match, If-None-Match, If-Modified-Since und If-Unmodified-Since.

  • Sie können Leasen eines BLOB aufrufen, um das BLOB für einen Zeitraum von einer Minute (oder länger, bei Verlängerung der Lease) für andere Schreibvorgänge zu sperren.

  • Mithilfe der Sequenznummer des BLOB können Sie sicherzustellen, dass bei der Wiederholung einer Anforderung, für die keine Antwort empfangen wurde, keine parallelen Updatevorgänge bewirkt werden. Dieser Ansatz empfiehlt sich besonders für Clients, bei denen ein hoher Durchsatz für Seitenschreibvorgänge erforderlich ist. Er wird im folgenden Abschnitt ausführlich beschrieben.

Verwenden der Seitenblob-Sequenznummer für das Wiederholen von Anforderungen

Wenn für einen Aufruf von Put Page ein Timeout auftritt oder keine Antwort zurückgegeben wird, kann nicht mit Sicherheit festgestellt werden, ob die Anforderung erfolgreich verarbeitet wurde. Deshalb müssen Sie die Anforderung wiederholen. Aufgrund der verteilten Struktur der Windows Azure-Speicherdienste wird die ursprüngliche Anforderung möglicherweise erst verarbeitet, nachdem die wiederholte Anforderung erfolgreich abgeschlossen wurde. Die verzögerte ursprüngliche Anforderung kann andere Updates überschreiben und somit zu unerwarteten Ergebnissen führen. Die folgende Sequenz veranschaulicht einen möglichen Ablauf:

  1. Für eine Put Page-Anforderung zum Schreiben von Wert "X" in Seite 0 tritt ein Timeout auf, oder es wird keine Antwort zurückgegeben.

  2. Eine wiederholte Anforderung zum Schreiben von Wert "X" in Seite 0 wird erfolgreich abgeschlossen.

  3. Eine Anforderung zum Schreiben von Wert "Y" in Seite 0 wird erfolgreich abgeschlossen.

  4. Die ursprüngliche Anforderung war erfolgreich, und Wert "x" wird in Seite 0 geschrieben.

  5. Beim Lesen von Seite 0 wird Wert "X" zurückgegeben, während der Client an diesem Punkt Wert "Y" erwartet.

Diese Art von Konflikt kann auftreten, wenn die ursprüngliche Anforderung keinen Statuscode zwischen 100-499 oder 503 (Server ausgelastet) zurückgibt. Wird einer dieser Statuscodes zurückgegeben, können Sie sicher sein, dass die Anforderung erfolgreich abgeschlossen wurde oder fehlgeschlagen ist. Wenn der Dienst jedoch einen Statuscode außerhalb dieses Bereichs zurückgibt, kann der Status der ursprünglichen Anforderung nicht bestimmt werden.

Um diese Art von Konflikt zu verhindern, können Sie mit der Sequenznummer des Seitenblobs sicherstellen, dass bei der Wiederholung einer Anforderung im Folgenden nicht die ursprüngliche Anforderung erfolgreich ausgeführt wird. Dazu sollten Sie die Sequenznummer vor dem Wiederholen der ursprünglichen Anforderung inkrementieren. Anschließend können Sie mit den bedingten Sequenznummernheadern sicherstellen, dass die Anforderung fehlschlägt, wenn die zugehörige Sequenznummer nicht der erwarteten Sequenznummer entspricht. Die folgende Sequenz veranschaulicht diese Vorgehensweise:

  1. Der Client erstellt mit Put Blob ein Seitenblob und legt seine Sequenznummer auf 0 fest.

  2. Für eine Put Page-Anforderung zum Schreiben von Wert "X" in Seite 0, wobei der if-sequence-number-lt-Header auf 1 festgelegt ist, tritt ein Timeout auf, oder es wird keine Antwort zurückgegeben.

  3. Der Client ruft Set Blob-Eigenschaften auf, um die Sequenznummer auf 1 zu aktualisieren.

  4. Eine wiederholte Anforderung zum Schreiben von Wert "X" in Seite 0, wobei if-sequence-number-lt auf 2 festgelegt ist, wird erfolgreich ausgeführt.

  5. Eine Anforderung zum Schreiben von Wert "Y" in Seite 0, wobei if-sequence-number-lt auf 2 festgelegt ist, wird erfolgreich ausgeführt.

  6. Die ursprüngliche Anforderung wird schließlich verarbeitet, sie schlägt jedoch fehl, da sie die Bedingung angibt, dass die Sequenznummer kleiner als 1 sein muss (d. h., der if-sequence-num-lt-Header ist auf 1 festgelegt). Als Fehler wird SequenceNumberConditionNotMet (HTTP-Statuscode 412 - Vorbedingung nicht erfüllt) zurückgegeben.

  7. Beim Lesen von Seite 0 wird der erwartete Wert "Y" zurückgegeben.

Anzeigen:
© 2014 Microsoft