Amazon Simple Storage Service
Entwicklerhandbuch (API-Version 2006-03-01)

Virtuelles Hosting bei Buckets

Im Allgemeinen ist das virtuelle Hosting das beste Verfahren, um mehrere Websites mit einem Webserver zu unterstützen. Eine Möglichkeit, zwischen den Websites zu unterscheiden, ist die Verwendung des Hostnamens in der Anforderung anstelle des Pfadnamens in der URI. Eine gewöhnliche Amazon S3 REST-Anforderung gibt einen Bucket an, indem sie die erste durch Schrägstrich abgetrennte Komponente des Pfads der Anforderungs-URI verwendet. Alternativ können Sie das virtuelle Hosting von Amazon S3 verwenden, um mit dem HTTP-Header Host einen Bucket in einem REST-API-Aufruf anzusprechen. In der Praxis interpretiert Amazon S3 Host so, dass die meisten Buckets automatisch (für begrenzte Anforderungtypen) unter http://bucketname.s3.amazonaws.com zur Verfügung stehen. Wenn Sie Ihrem Bucket denselben Namen wie Ihrer registrierten Domäne geben und diesen Namen dann zu einem DNS-Alias für Amazon S3 machen, können Sie die URL Ihrer Amazon S3-Ressourcen vollständig anpassen, z. B. http://my.bucketname.com/.

Benutzerdefinierte URLs sind zum einen attraktiv, haben aber auch den Vorteil des virtuellen Hostings, nämlich im „Root-Verzeichnis” des virtuellen Servers Ihres Buckets zu veröffentlichen. Diese Fähigkeit kann wichtig sein, da viele vorhandene Anwendungen nach Dateien an diesem Standardspeicherort suchen. Beispielsweise wird erwartet, dass favicon.ico, robots.txt, crossdomain.xml im Stamm gefunden werden können.

Derzeit unterstützt Amazon S3 virtuellen Hosted-Style- und Path-Style-Zugriff in allen Regionen, dies ändert sich jedoch (siehe folgenden wichtigen Hinweis). Für die Path-Style-Syntax ist es erforderlich, dass Sie beim Versuch, auf einen Bucket zuzugreifen, den regionenspezifischen Endpunkt verwenden. Wenn Sie z. B. über einen Bucket mit dem Namen mybucket verfügen, der sich in der Region EU (Irland) befindet, Sie die Path-Style-Syntax verwenden möchten und das Objekt puppy.jpg heißt, dann lautet die korrekte URI http://s3-eu-west-1.amazonaws.com/mybucket/puppy.jpg.

Sie erhalten einen HTTP-Antwortcode „307 Temporärer Umleitungsfehler” und eine Mitteilung, in der die korrekte URI für die Ressource angegeben wird, wenn Sie versuchen, auf einen Bucket mit einer Path-Style-Syntax, die eines der folgenden Elemente verwendet, außerhalb der Region USA Ost (Nord-Virginia) zuzugreifen:

  • http://s3.amazonaws.com

  • Einen anderen Endpunkt für eine Region als den, in dem sich der Bucket befindet. Wenn Sie z. B. http://s3-us-west-1.amazonaws.com für einen Bucket verwenden, der in der Region USA West (Nordkalifornien) erstellt wurde.

Wichtig

Buckets, die nach dem 30. September 2020 erstellt werden, unterstützen nur virtuelle Hosted-Style-Anfragen. Path-Style-Anfragen werden weiterhin für Buckets unterstützt, die an oder vor diesem Datum erstellt wurden. Weitere Informationen finden Sie unter Amazon S3 Path Deprecation Plan – The Rest of the Story.

Wenn Sie anstelle des regionsspezifischen Endpunkts (z. B. s3-us-west-1.amazonaws.com) den Endpunkt USA Ost (Nord-Virginia) (s3.amazonaws.com) verwenden, leitet Amazon S3 alle Anforderungen im Stil des virtuellen Hostings standardmäßig an die Region USA Ost (Nord-Virginia) weiter. Wenn Sie in einer bis zum 20. März 2019 gestarteten Region einen Bucket erstellen, aktualisiert Amazon S3 den DNS, damit die Anforderung an die richtige Position umgeleitet wird. Dies kann einige Zeit dauern. In der Zwischenzeit gilt die Standardregel und die Anforderung im Stil – eines virtuellen Hostings wird an die Region USA Ost (Nord-Virginia) gesendet.Amazon S3 leitet diese dann mit einer „HTTP 307“-Umleitung zur richtigen Region.

Für S3-Buckets in nach dem 20. März 2019 gestarteten Regionen leitet der DNS die Anforderung nicht direkt an die AWS-Region weiter, in der sich der Bucket befindet. Stattdessen wird ein "HTTP 400 Bad Request"-Fehler zurückgegeben.

Weitere Informationen finden Sie unter Anfrageumleitung und die REST API.

Bei Verwendung von Buckets im Stil eines virtuellen Hostings mit SSL stimmt das SSL-Platzhalterzertifikat nur mit Buckets überein, die keine Punkte enthalten. Um dies zu umgehen, verwenden Sie HTTP oder schreiben Sie Ihre eigene Logik zur Verifizierung von Zertifikaten.

Bucket-Spezifikation für HTTP-Host-Header

So lange Ihre GET-Anforderung nicht den SSL-Endpunkt verwendet, können Sie mit dem HTTP-Host-Header den Bucket für die Anforderung festlegen. Der Host-Header in einer REST-Anforderung wird folgendermaßen interpretiert:

  • Wenn der Header Host ausgelassen wird oder der Wert „s3.amazonaws.com“ lautet, ist der Bucket für die Anforderung die erste durch Schrägstrich abgetrennte Komponente der Anforderungs-URI und der Schlüssel für die Anforderung bildet den Rest der Anforderungs-URI. Dies ist die übliche Methode wie im ersten und zweiten Beispiel in diesem Abschnitt dargestellt. Das Auslassen des Host-Headers ist nur bei HTTP 1.0-Anforderungen möglich.

  • Wenn andernfalls der Wert des Host-Headers mit „.s3.amazonaws.com“ endet, ist der Bucket-Name die führende Komponente im Wert des Host-Headers bis „.s3.amazonaws.com“. Der Schlüssel für die Anforderung ist die Anforderungs-URI. Diese Interpretation stellt Buckets als Unterdomänen von s3.amazonaws.com bereit (siehe das dritte und vierte Beispiel in diesem Abschnitt).

  • Ansonsten ist der Bucket für die Anforderung der klein geschriebene Wert des Host-Headers und die Schlüssel für die Anforderung ist die Anforderungs-URI. Diese Interpretation ist nützlich, wenn Sie als DNS-Namen Ihren Bucket-Namen registriert und diesen Namen so konfiguriert haben, dass er ein CNAME-Alias für Amazon S3 ist. Das Verfahren zum Registrieren von Domänennamen und Konfigurieren von DNS ist nicht Gegenstand dieses Leitfadens. Das Ergebnis wird jedoch im letzten Beispiel in diesem Abschnitt dargestellt.

Beispiele

In diesem Abschnitt finden Sie Beispiel-URLs und -anforderungen.

Beispiel Methode im Pfadstil

In diesem Beispiel wird johnsmith.net als Bucket-Name und homepage.html als Schlüsselname verwendet.

Die URL lautet wie folgt:

http://s3.amazonaws.com/johnsmith.net/homepage.html

die Anforderung lautet wie folgt:

GET /johnsmith.net/homepage.html HTTP/1.1 Host: s3.amazonaws.com

die Anforderung mit HTTP 1.0 unter Auslassen des host-Headers lautet wie folgt:

GET /johnsmith.net/homepage.html HTTP/1.0

Informationen zu mit DNS kompatiblen Namen finden Sie unter Einschränkungen. Weitere Informationen zu Schlüsseln finden Sie unter Schlüssel.

Beispiel Methode im Stil des virtuellen Hostings

In diesem Beispiel wird johnsmith.net als Bucket-Name und homepage.html als Schlüsselname verwendet.

Die URL lautet wie folgt:

http://johnsmith.net.s3.amazonaws.com/homepage.html

die Anforderung lautet wie folgt:

GET /homepage.html HTTP/1.1 Host: johnsmith.net.s3.amazonaws.com

Für die Methode im Stil des virtuellen Hostings muss der Bucket-Name DNS-konform sein.

Beispiel Methode im Stil des virtuellen Hostings für einen Bucket in einer anderen Region als USA Ost (Nord-Virginia)

In diesem Beispiel wird johnsmith.eu als Name für einen Bucket in der Region EU (Irland) und homepage.html als Schlüsselname verwendet.

Die URL lautet wie folgt:

http://johnsmith.eu.s3-eu-west-1.amazonaws.com/homepage.html

die Anforderung lautet wie folgt:

GET /homepage.html HTTP/1.1 Host: johnsmith.eu.s3-eu-west-1.amazonaws.com

Anstelle des regionsspezifischen Endpunkts kann auch der Endpunkt der Region USA Ost (Nord-Virginia) verwendet werden, ungeachtet der Region, in der sich der Bucket befindet.

http://johnsmith.eu.s3.amazonaws.com/homepage.html

die Anforderung lautet wie folgt:

GET /homepage.html HTTP/1.1 Host: johnsmith.eu.s3.amazonaws.com

Beispiel CNAME-Methode

In diesem Beispiel wird www.johnsmith.net als Bucket-Name und homepage.html als Schlüsselname verwendet. Um diese Methode zu verwenden, müssen Sie den DNS-Namen als CNAME-Alias für bucketname.s3.amazonaws.com konfigurieren.

Die URL lautet wie folgt:

http://www.johnsmith.net/homepage.html

Das Beispiel ist wie folgt:

GET /homepage.html HTTP/1.1 Host: www.johnsmith.net

Anpassen von Amazon S3-URLs mit CNAMEs

Abhängig von den Anforderungen können Sie die Anzeige von s3.amazonaws.com auf der Website oder im Service gegebenenfalls unterbinden. Wenn Sie die Bilder der Website beispielsweise in Amazon S3 hosten, möchten Sie möglicherweise, dass http://images.johnsmith.net/ anstelle von http://johnsmith-images.s3.amazonaws.com/ angezeigt wird.

Der Bucket-Name muss dem CNAME entsprechen. http://images.johnsmith.net/filename würde daher http://images.johnsmith.net.s3.amazonaws.com/filename entsprechen, wenn ein CNAME erstellt würde, um images.johnsmith.net und images.johnsmith.net.s3.amazonaws.com einander zuzuordnen.

Auf Buckets mit einem mit DNS kompatiblen Namen kann wie folgt verwiesen werden: http://[BucketName].s3.amazonaws.com/[Filename], z. B. http://images.johnsmith.net.s3.amazonaws.com/mydog.jpg. Durch die Verwendung von CNAME können Sie images.johnsmith.net einem Amazon S3-Host-Namen zuordnen, damit die vorherige URL als http://images.johnsmith.net/mydog.jpg angezeigt wird.

Der CNAME-DNS-Datensatz muss einen Alias des Domänennamens für den entsprechenden Host-Namen im Stil des virtuellen Hostings erstellen. Wenn Ihr Bucket-Name und Ihr Domänenname beispielsweise images.johnsmith.net lauten, sollte der CNAME-Datensatz einen Alias für images.johnsmith.net.s3.amazonaws.com erstellen.

images.johnsmith.net CNAME images.johnsmith.net.s3.amazonaws.com.

Als Aliasziel kann auch s3.amazonaws.com angegeben werden. Dies führt jedoch möglicherweise zu zusätzlichen HTTP-Umleitungen.

Amazon S3 verwendet den Host-Namen, um den Bucket-Namen zu ermitteln. Nehmen wir beispielsweise an, dass Sie www.example.com als CNAME für www.example.com.s3.amazonaws.com konfiguriert haben. Wenn Sie auf http://www.example.com zugreifen, empfängt Amazon S3 eine Anforderung, die in etwa wie folgt aussieht:

GET / HTTP/1.1 Host: www.example.com Date: date Authorization: signatureValue

Amazon S3 sieht nur den ursprünglichen Host-Namen www.example.com und kennt die zum Auflösen der Anforderung verwendete CNAME-Zuordnung nicht. CNAME und Bucket-Name müssen also identisch sein.

In einem CNAME können alle Amazon S3-Endpunkte verwendet werden. Beispielsweise kann s3-ap-southeast-1.amazonaws.com in CNAMEs verwendet werden. Weitere Informationen zu Endpunkten finden Sie unter Anforderungsendpunkte.

So verknüpfen Sie einen Host-Namen unter Verwendung von CNAMEs mit einem Amazon S3-Bucket

  1. Wählen Sie einen Host-Namen aus, der zu einer von Ihnen kontrollierten Domäne gehört. Dieses Beispiel verwendet die Unterdomäne images der Domäne johnsmith.net.

  2. Erstellen Sie einen Bucket, der dem Host-Namen entspricht. In diesem Beispiel lauten der Host- und der Bucket-Name images.johnsmith.net.

    Anmerkung

    Der Bucket-Name muss exakt mit dem Host-Namen übereinstimmen.

  3. Erstellen Sie einen CNAME-Datensatz, der den Host-Namen als Alias für den Amazon S3-Bucket definiert. Beispiel:

    images.johnsmith.net CNAME images.johnsmith.net.s3.amazonaws.com

    Wichtig

    Aus Gründen des Anforderungs-Routings muss der CNAME-Datensatz genau wie im vorherigen Beispiel dargestellt definiert werden. Andernfalls kann sich trotz richtig erscheinender Funktion unvorhersehbares Verhalten ergeben.

    Anmerkung

    Das Verfahren für die Konfiguration von DNS ist abhängig von Ihrem DNS-Server oder DNS-Anbieter. Spezifische Informationen finden Sie in Ihrer Serverdokumentation oder erhalten Sie von Ihrem Anbieter.

Einschränkungen

Virtuelle Host-URLs werden nur für Nicht-SLL-(HTTP)-Anforderungen unterstützt.

Anmerkung

Die SOAP-Unterstützung über HTTP ist veraltet, steht über HTTPS aber noch zur Verfügung. Die neuen Amazon S3-Funktionen werden unter SOAP nicht unterstützt. Wir empfehlen, entweder die REST API oder die AWS SDKs zu verwenden.

Abwärtskompatibilität

Frühe Versionen von Amazon S3 haben den HTTP-Host-Header fälschlicherweise ignoriert. Anwendungen, die von diesem nicht dokumentierten Verhalten abhängig sind, müssen aktualisiert werden, um den Host-Header korrekt festzulegen. Da Amazon S3 den Bucketnamen bei Vorhandensein von Host ermittelt, besteht das wahrscheinlichste Symptom dieses Problems in der Ausgabe eines unerwarteten NoSuchBucket-Fehlerergebniscodes.