View a markdown version of this page

Signaturberechnungen für den Autorisierungs-Header: Übertragung von Nutzdaten in mehreren Blöcken (Chunked Upload) (AWS Signatur (Version 4) - Amazon Simple Storage Service
Berechnung der Seed-SignaturDen Chunk-Körper definierenBeispiel: PUT-Objekt

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Signaturberechnungen für den Autorisierungs-Header: Übertragung von Nutzdaten in mehreren Blöcken (Chunked Upload) (AWS Signatur (Version 4)

Wie unter beschrieben-Übersicht, haben Sie bei der Authentifizierung von Anfragen mithilfe des Authorization Headers die Möglichkeit, die Payload in Blöcken hochzuladen. Sie können Daten in Blöcken mit fester oder variabler Größe senden. In diesem Abschnitt wird der Prozess zur Berechnung der Signatur beim Block-Upload beschrieben, wie Sie den Chunk-Body erstellen und wie das verzögerte Signieren funktioniert, wenn Sie den Chunk zuerst hochladen und seine Signatur im nachfolgenden Chunk senden. Der Beispielabschnitt (sieheBeispiel: PUT-Objekt) zeigt Signaturberechnungen und die daraus resultierenden Authorization Header, die Sie als Testsuite zur Überprüfung Ihres Codes verwenden können.

Anmerkung

Wenn Sie Daten in einer Reihe von Blöcken übertragen, müssen Sie einen der folgenden Schritte ausführen:

  • Geben Sie die Gesamtlänge des Inhalts (Objektlänge in Byte plus Metadaten in jedem Block) mithilfe des Content-Length HTTP-Headers explizit an. Dazu müssen Sie die Gesamtlänge der Nutzlast, einschließlich der Metadaten, die Sie in jedem Chunk senden, vorab berechnen, bevor Sie Ihre Anfrage starten.

  • Geben Sie den HTTP-Header anTransfer-Encoding. Wenn Sie den Transfer-Encoding Header einbeziehen und einen anderen Wert als angebenidentity, müssen Sie den Content-Length Header weglassen.

Bei allen Anfragen müssen Sie den x-amz-decoded-content-length Header angeben, der die Größe des Objekts in Byte angibt.

Jede Berechnung der Blocksignatur beinhaltet die Signatur des vorherigen Blocks. Zunächst erstellen Sie eine Startsignatur, die nur die Header verwendet. Sie verwenden die Startsignatur bei der Signaturberechnung des ersten Blocks. Für jeden nachfolgenden Chunk erstellen Sie eine Chunk-Signatur, die die Signatur des vorherigen Chunks enthält. Somit sind die Chunk-Signaturen miteinander verkettet; das heißt, die Signatur von Chunk n ist eine Funktion F (Chunk n, signature (chunk n-1)). Die Verkettung stellt sicher, dass Sie die Chunks in der richtigen Reihenfolge senden.

Gehen Sie wie folgt vor, um einen Upload in Blöcken durchzuführen:

  1. Entscheiden Sie sich für die Größe des Payload-Chunks. Sie benötigen dies, wenn Sie den Code schreiben.

    Die Chunk-Größe muss mindestens 8 KB betragen. Für eine bessere Leistung empfehlen wir eine Chunk-Größe von mindestens 64 KB. Diese Chunk-Größe gilt für alle Chunks außer dem letzten. Der letzte Chunk, den Sie senden, kann kleiner als 8 KB sein. Wenn Ihre Nutzlast klein ist und in einen Chunk passt, kann sie kleiner als die 8 KB sein.

  2. Erstellen Sie die Seed-Signatur für die Aufnahme in den ersten Chunk. Weitere Informationen finden Sie unter Berechnung der Seed-Signatur.

  3. Erstellen Sie den ersten Chunk und streamen Sie ihn. Weitere Informationen finden Sie unter Den Chunk-Körper definieren.

  4. Berechnen Sie für jeden nachfolgenden Chunk die Chunk-Signatur, die die vorherige Signatur in der von Ihnen signierten Zeichenfolge enthält, erstellen Sie den Chunk und senden Sie ihn. Weitere Informationen finden Sie unter Den Chunk-Körper definieren.

  5. Senden Sie den letzten zusätzlichen Block, der mit den anderen Blöcken in der Konstruktion identisch ist, aber keine Datenbytes enthält. Weitere Informationen finden Sie unter Den Chunk-Körper definieren.

Berechnung der Seed-Signatur

Das folgende Diagramm veranschaulicht den Prozess der Berechnung der Startsignatur.

Der Prozess der Berechnung der Samensignatur.

In der folgenden Tabelle werden die im Diagramm dargestellten Funktionen beschrieben. Für diese Funktionen muss Code implementiert werden.

Funktion Description
Lowercase() Wandeln Sie die Zeichenfolge in Kleinbuchstaben um.
Hex() Kodierung in Kleinbuchstaben im Basis-16-Format.
SHA256Hash() Kryptografische Hash-Funktion des Secure Hash Algorithm (SHA).
HMAC-SHA256() Berechnet HMAC unter Verwendung des SHA256-Algorithmus mit dem bereitgestellten Signaturschlüssel. Dies ist die endgültige Signatur.
Trim() Entfernen Sie alle führenden oder nachgestellten Leerzeichen.
UriEncode()

URI kodieren jedes Byte. UriEncode() muss die folgenden Regeln durchsetzen:

  • URI kodiert jedes Byte mit Ausnahme der nicht reservierten Zeichen: „A“–„Z“, „a“–„z“, „0“–„9“, „-“, „.“, „_“ und „~“.

  • Das Leerzeichen ist ein reserviertes Zeichen und muss als „%20“ (und nicht als „+“) codiert werden.

  • Jedes URI-codierte Byte besteht aus einem „%“ und dem zweistelligen Hexadezimalwert des Bytes.

  • Buchstaben im Hexadezimalwert müssen in Großbuchstaben geschrieben sein, zum Beispiel „%1A“.

  • Kodieren Sie den Schrägstrich „/“ überall außer im Objektschlüsselnamen. Wenn der Objektschlüsselname beispielsweise photos/Jan/sample.jpg lautet, wird der Schrägstrich im Schlüsselnamen nicht codiert.

Wichtig

Die von Ihrer Entwicklungsplattform bereitgestellten UriEncode Standardfunktionen funktionieren möglicherweise aufgrund von Unterschieden in der Implementierung und den damit verbundenen Mehrdeutigkeiten in den zugrunde liegenden RFCs nicht. Wir empfehlen Ihnen, Ihre eigene benutzerdefinierte UriEncode Funktion zu schreiben, um sicherzustellen, dass Ihre Codierung funktioniert.

Das Folgende ist eine Beispielfunktion UriEncode () in Java.

public static String UriEncode(CharSequence input, boolean encodeSlash) {
          StringBuilder result = new StringBuilder();
          for (int i = 0; i < input.length(); i++) {
              char ch = input.charAt(i);
              if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '-' || ch == '~' || ch == '.') {
                  result.append(ch);
              } else if (ch == '/') {
                  result.append(encodeSlash ? "%2F" : ch);
              } else {
                  result.append(toHexUTF8(ch));
              }
          }
          return result.toString();
      }

Hinweise zum Signieren finden Sie unterSignaturberechnungen für den Autorisierungs-Header: Übertragung der Nutzlast in einem einzigen Block (AWS Signatur (Version 4). Der Vorgang ist derselbe, mit der Ausnahme, dass sich die Erstellung von wie folgt CanonicalRequest unterscheidet:

  • Zusätzlich zu den Anforderungsheadern, die Sie hinzufügen möchten, müssen Sie die folgenden Header angeben:

    Header Description
    x-amz-content-sha256

    Dieser Header ist für alle AWS Signature Version 4-Anfragen erforderlich. Stellen Sie den Wert auf ein, STREAMING-AWS4-HMAC-SHA256-PAYLOAD um anzugeben, dass die Signatur nur Header abdeckt und dass keine Nutzlast vorhanden ist.
    Content-Encoding

    Legen Sie den Wert auf aws-chunked fest.

    Amazon S3 unterstützt mehrere Werte für die Inhaltskodierung. Sie können Ihre benutzerdefinierte Inhaltskodierung angeben, wenn Sie die Streaming-API von Signature Version 4 verwenden.

    Beispiel:

    Content-Encoding : aws-chunked,gzip

    Amazon S3 speichert das resultierende Objekt ohne den aws-chunked Wert im content-encoding Header. Wenn dies der einzige Wert aws-chunked ist, den Sie im content-encoding Header übergeben, betrachtet S3 den content-encoding Header als leer und gibt diesen Header nicht zurück, wenn Sie das Objekt abrufen.

    x-amz-decoded-content-length Stellen Sie den Wert auf die Länge der Daten in Byte ein, die aufgeteilt werden sollen, ohne Metadaten zu zählen. Wenn Sie beispielsweise eine 4-GB-Datei hochladen, legen Sie den Wert auf 4294967296 fest. Dies ist die Rohgröße des hochzuladenden Objekts (Daten, die Sie in Amazon S3 speichern möchten).
    Content-Length

    Stellen Sie den Wert auf die tatsächliche Größe des übertragenen HTTP-Texts ein, der die Länge Ihrer Daten (eingestellter Wert fürx-amz-decoded-content-length) sowie die Chunk-Metadaten umfasst. Jeder Chunk hat Metadaten, wie z. B. die Signatur des vorherigen Chunks. Chunk-Berechnungen werden im folgenden Abschnitt behandelt. Wenn Sie den Transfer-Encoding Header einbeziehen und einen anderen Wert als angebenidentity, dürfen Sie den Content-Length Header nicht einschließen.

Sie senden den ersten Block mit der Seed-Signatur. Sie müssen den Chunk wie im folgenden Abschnitt beschrieben erstellen.

Den Chunk-Körper definieren

Alle Chunks enthalten einige Metadaten. Jeder Chunk muss der folgenden Struktur entsprechen:

string(IntHexBase(chunk-size)) + ";chunk-signature=" + signature + \r\n + chunk-data + \r\n

Wobei Folgendes gilt:

  • IntHexBase()ist eine Funktion, die Sie schreiben, um eine Ganzzahl-Blockgröße in eine Hexadezimalgröße umzuwandeln. Wenn Chunk-Size beispielsweise 65536 ist, ist die hexadezimale Zeichenfolge „10000".

  • chunk-sizeist die Größe der Chunk-Daten in Byte ohne Metadaten. Wenn Sie beispielsweise ein 65-KB-Objekt hochladen und eine Chunk-Größe von 64 KB verwenden, laden Sie die Daten in drei Blöcken hoch: Der erste Block wäre 64 KB groß, der zweite 1 KB und der letzte Block hätte 0 Byte.

  • signatureFür jeden Block berechnen Sie die Signatur mithilfe der folgenden Zeichenfolge zum Signieren. Für den ersten Block verwenden Sie die Seed-Signatur als vorherige Signatur.

    Der Prozess der Berechnung der Startsignatur, bei dem verschiedene Komponenten der zu signierenden Zeichenfolge angezeigt werden.

Die Größe der letzten Chunk-Daten, die Sie senden, ist 0, obwohl der Chunk-Text immer noch Metadaten enthält, einschließlich der Signatur des vorherigen Chunks.

Beispiel: PUT-Objekt

Sie können die Beispiele in diesem Abschnitt als Referenz verwenden, um die Signaturberechnungen in Ihrem Code zu überprüfen. Bevor Sie sich die Beispiele ansehen, beachten Sie Folgendes:

  • Bei den Signaturberechnungen in diesen Beispielen werden die folgenden Beispiel-Sicherheitsanmeldeinformationen verwendet.

    Parameter Wert
    AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
    AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  • Alle Beispiele verwenden den Anforderungszeitstempel 20130524T000000Z (). Fri, 24 May 2013 00:00:00 GMT

  • Alle Beispiele werden als Bucket-Namen verwendet. examplebucket

  • Es wird davon ausgegangen, dass sich der Bucket in der Region USA Ost (Nord-Virginia) befindet, und die Anmeldeinformationen Scope und die Signing Key Berechnungen werden us-east-1 als Regionsspezifizierer verwendet. Weitere Informationen finden Sie unter Regionen und Endpunkte in der Allgemeinen Referenz zu Amazon Web Services.

  • Sie können Anfragen im Pfadstil oder im virtuell gehosteten Stil verwenden. In den folgenden Beispielen werden beispielsweise Anfragen im virtuell gehosteten Stil verwendet: 

    https://examplebucket.s3.amazonaws.com/photos/photo1.jpg

    Weitere Informationen finden Sie unter Virtuelles Hosting von Buckets im Amazon Simple Storage Service-Benutzerhandbuch.

Das folgende Beispiel sendet eine PUT Anfrage zum Hochladen eines Objekts. Bei den Signaturberechnungen wird Folgendes vorausgesetzt:

  • Sie laden eine 65-KB-Textdatei hoch, und der Dateiinhalt ist eine einstellige Zeichenfolge, die aus dem Buchstaben 'a' besteht.

  • Die Chunk-Größe beträgt 64 KB. Infolgedessen wird die Nutzlast in drei Blöcken hochgeladen: 64 KB, 1 KB und der letzte Block mit 0 Byte an Chunk-Daten.

  • Das resultierende Objekt hat den Schlüsselnamen. chunkObject.txt

  • Sie fordern REDUCED_REDUNDANCY als Speicherklasse an, indem Sie den x-amz-storage-class Anforderungsheader hinzufügen.

Hinweise zur API-Aktion finden Sie unter PutObject. Die allgemeine Anforderungssyntax lautet wie folgt: 

PUT /examplebucket/chunkObject.txt HTTP/1.1
Host: s3.amazonaws.com
x-amz-date: 20130524T000000Z 
x-amz-storage-class: REDUCED_REDUNDANCY
Authorization: SignatureToBeCalculated
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
Content-Encoding: aws-chunked
x-amz-decoded-content-length: 66560
Content-Length: 66824
<Payload>

Die folgenden Schritte zeigen Signaturberechnungen.

  1. Seed-Signatur — Erstellen Sie eine zu signierende Zeichenfolge
    1. CanonicalRequest

      PUT
/examplebucket/chunkObject.txt

content-encoding:aws-chunked
content-length:66824
host:s3.amazonaws.com
x-amz-content-sha256:STREAMING-AWS4-HMAC-SHA256-PAYLOAD
x-amz-date:20130524T000000Z
x-amz-decoded-content-length:66560
x-amz-storage-class:REDUCED_REDUNDANCY

content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class
STREAMING-AWS4-HMAC-SHA256-PAYLOAD

      In der kanonischen Anfrage ist die dritte Zeile leer, da die Anfrage keine Abfrageparameter enthält. Die letzte Zeile ist die konstante Zeichenfolge, die als Wert der Hash-Nutzlast bereitgestellt wird. Diese sollte dem Wert von entsprechen. x-amz-content-sha256 header

    2. StringToSign

      AWS4-HMAC-SHA256
20130524T000000Z
20130524/us-east-1/s3/aws4_request
cee3fed04b70f867d036f722359b0b1f2f0e5dc0efadbc082b76c4c60e316455

      Anmerkung

      Informationen zu den einzelnen Zeilen in der zu signierenden Zeichenfolge finden Sie in dem Diagramm, das die Berechnung der Startsignatur erklärt.

  2. SigningKey

    signing key = HMAC-SHA256(HMAC-SHA256(HMAC-SHA256(HMAC-SHA256("AWS4" + "<YourSecretAccessKey>","20130524"),"us-east-1"),"s3"),"aws4_request")

  3. Seed-Signatur

    4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9

  4. Authorization-Header

    Der resultierende Authorization-Header lautet wie folgt:

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class,Signature=4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9

  5. Block 1: (65536 Byte, mit dem Wert 97 für den Buchstaben 'a')

    1. Zu signierende Chunk-Zeichenfolge:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
bf718b6f653bebc184e1479f1935b8da974d701b893afcf49e701f3e2f9f9c5a

      Anmerkung

      Informationen zu den einzelnen Zeilen der zu signierenden Zeichenfolge finden Sie im vorherigen Diagramm, das die verschiedenen Komponenten der zu signierenden Zeichenfolge zeigt (die letzten drei Zeilen lauten z. B., previous-signaturehash(""), undhash(current-chunk-data)).

    2. Signatur des Blocks:

      ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648

    3. Gesendete Chunk-Daten:

      10000;chunk-signature=ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648
<65536-bytes>
  6. Chunk 2: (1024 Byte, mit dem Wert 97 für den Buchstaben 'a')

    1. Zu signierende Chunk-Zeichenfolge:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
2edc986847e209b4016e141a6dc8716d3207350f416969382d431539bf292e4a

    2. Chunk-Signatur:

      0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497

    3. Gesendete Chunk-Daten:

      400;chunk-signature=0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497
<1024 bytes>
  7. Block 3: (0-Byte-Daten)

    1. Zu signierende Chunk-Zeichenfolge:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

    2. Chunk-Signatur:

      b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9

    3. Gesendete Chunk-Daten:

      0;chunk-signature=b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9