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.

Fehlerbehebung für CORS

Die folgenden Themen können Ihnen helfen, einige häufig auftretende CORS Probleme im Zusammenhang mit S3 zu beheben.

403 Unerlaubter Fehler: CORS ist für diesen Bucket nicht aktiviert

Der folgende 403 Forbidden Fehler tritt auf, wenn eine ursprungsübergreifende Anfrage an Amazon S3 gesendet, aber nicht in Ihrem S3-Bucket konfiguriert CORS ist.

Fehler: HTTP/1.1 403 Forbidden CORS Response: CORS ist für diesen Bucket nicht aktiviert.

Bei der CORS Konfiguration handelt es sich um ein Dokument oder eine Richtlinie mit Regeln, die die Ursprünge, denen Sie den Zugriff auf Ihren Bucket erlauben, die Operationen (HTTPMethoden), die Sie für jeden Ursprung unterstützen, und andere vorgangsspezifische Informationen festlegen. Erfahren Sie, wie Sie mithilfe der Amazon S3-Konsole CORS auf S3 konfigurieren AWS SDKs, und RESTAPI. Weitere Informationen CORS und Beispiele für eine CORS Konfiguration finden Sie unter Elements of CORS.

403 Unzulässiger Fehler: Diese CORS Anfrage ist nicht zulässig

Der folgende 403 Forbidden Fehler wird angezeigt, wenn eine CORS Regel in Ihrer CORS Konfiguration nicht mit den Daten in Ihrer Anfrage übereinstimmt.

Fehler: HTTP/1.1 403 Verbotene CORS Antwort: Diese CORS Anfrage ist nicht zulässig.

Daher kann dieser 403 Forbidden Fehler aus mehreren Gründen auftreten:

Für jede Anfrage, die Amazon S3 empfängt, müssen Sie eine CORS Regel in Ihrer CORS Konfiguration haben, die den Daten in Ihrer Anfrage entspricht.

Origin ist nicht erlaubt

Der Origin Header in einer CORS Anfrage an Ihren Bucket muss mit den Ursprüngen im AllowedOrigins Element in Ihrer CORS Konfiguration übereinstimmen. Ein Platzhalterzeichen ("*") im AllowedOrigins Element würde allen HTTP Methoden entsprechen. Weitere Informationen zum Aktualisieren des AllowedOrigins Elements finden Sie unter Konfiguration der gemeinsamen Nutzung von Ressourcen zwischen verschiedenen Quellen () CORS.

Wenn beispielsweise nur die http://www.example1.com Domäne im AllowedOrigins Element enthalten ist, würde bei einer von der http://www.example2.com Domäne gesendeten CORS Anfrage der 403 Forbidden Fehler angezeigt.

Das folgende Beispiel zeigt einen Teil einer CORS Konfiguration, die die http://www.example1.com Domain in das AllowedOrigins Element einbezieht.

"AllowedOrigins":[
   "http://www.example1.com"
]

Damit eine von der http://www.example2.com Domain gesendete CORS Anfrage erfolgreich ist, muss die http://www.example2.com Domain in das AllowedOrigins CORS Konfigurationselement aufgenommen werden.

"AllowedOrigins":[
   "http://www.example1.com"
   "http://www.example2.com"
]

Methoden sind nicht erlaubt

Die HTTP Methoden, die Access-Control-Request-Method in einer CORS Anfrage an Ihren Bucket angegeben sind, müssen mit der oder den Methoden übereinstimmen, die in dem AllowedMethods Element in Ihrer CORS Konfiguration aufgeführt sind. Ein Platzhalterzeichen ("*") in AllowedMethods würde allen HTTP Methoden entsprechen. Weitere Informationen zum Aktualisieren des AllowedOrigins Elements finden Sie unter Cross-Origin Resource Sharing () CORS konfigurieren.

In einer CORS Konfiguration können Sie die folgenden Methoden im AllowedMethods Element angeben:

Das folgende Beispiel zeigt einen Teil einer CORS Konfiguration, die die GET Methode im AllowedMethods Element enthält. Nur Anfragen, die die GET Methode enthalten, würden erfolgreich sein.

"AllowedMethods":[
   "GET"
]

Wenn eine HTTP Methode (z. B.PUT) in einer CORS Anfrage verwendet oder in einer CORS Preflight-Anfrage an Ihren Bucket enthalten war, die Methode jedoch nicht in Ihrer CORS Konfiguration vorhanden ist, würde die Anfrage zu einem 403 Forbidden Fehler führen. Um diese CORS Anfrage oder CORS Pre-Flight-Anfrage zuzulassen, muss die PUT Methode zu Ihrer CORS Konfiguration hinzugefügt werden.

"AllowedMethods":[
   "GET"
   "PUT"
]

Angeforderte Header sind nicht zulässig

Die im Header einer Pre-Flight-Anfrage aufgeführten Access-Control-Request-Headers Header müssen mit den Headern im AllowedHeaders Element in Ihrer Konfiguration übereinstimmen. CORS Eine Liste gängiger Header, die in Anfragen an Amazon S3 verwendet werden können, finden Sie unter Allgemeine Anforderungsheader. Weitere Informationen zur Aktualisierung des AllowedHeaders Elements finden Sie unter Konfiguration der ursprungsübergreifenden gemeinsamen Nutzung von Ressourcen (). CORS

Das folgende Beispiel zeigt einen Teil einer CORS Konfiguration, die den Authorization Header im AllowedHeaders Element enthält. Nur Anfragen für den Authorization Header wären erfolgreich.

"AllowedHeaders":  [
    "Authorization"
]

Wenn ein Header (zum Beispiel) in einer CORS Anfrage enthalten Content-MD5 war, der Header jedoch nicht in Ihrer CORS Konfiguration vorhanden ist, würde die Anfrage zu einem 403 Forbidden Fehler führen. Um diese CORS Anfrage zuzulassen, muss der Content-MD5 Header zu Ihrer CORS Konfiguration hinzugefügt werden. Wenn Sie Authorization sowohl Content-MD5 Header als auch Header in einer CORS Anfrage an Ihren Bucket übergeben möchten, stellen Sie sicher, dass beide Header im AllowedHeaders Element in Ihrer CORS Konfiguration enthalten sind.

"AllowedHeaders":  [
    "Authorization"
    "Content-MD5"
]           

Header wurden als Antwort nicht gefunden CORS

Das ExposeHeaders Element in Ihrer CORS Konfiguration identifiziert, welche Antwortheader Sie Skripten und Anwendungen, die in Browsern ausgeführt werden, als Antwort auf eine CORS Anfrage zugänglich machen möchten.

Wenn Ihre in Ihrem S3-Bucket gespeicherten Objekte neben den Antwortdaten auch benutzerdefinierte Metadaten (z. B.x-amz-meta-custom-header) enthalten, könnte dieser benutzerdefinierte Header zusätzliche Metadaten oder Informationen enthalten, auf die Sie über Ihren JavaScript clientseitigen Code zugreifen möchten. Standardmäßig blockieren Browser jedoch aus Sicherheitsgründen den Zugriff auf benutzerdefinierte Header. Um Ihrem Client den Zugriff auf benutzerdefinierte Header JavaScript zu ermöglichen, müssen Sie den Header in Ihre Konfiguration aufnehmen. CORS

Im folgenden Beispiel ist der x-amz-meta-custom-header1 Header im Element enthalten. ExposeHeaders Das x-amz-meta-custom-header2 ist nicht im ExposeHeaders Element enthalten und fehlt in der CORS Konfiguration. In der Antwort würden nur die im ExposeHeaders Element enthaltenen Werte zurückgegeben. Wenn die Anfrage den x-amz-meta-custom-header2 Header im Access-Control-Expose-Headers Header enthalten würde, würde die Antwort trotzdem a zurückgeben200 OK. Es x-amz-meta-custom-header würde jedoch zum Beispiel nur der zulässige Header zurückgegeben und in der Antwort angezeigt.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1"
]           

Um sicherzustellen, dass alle Header in der Antwort erscheinen, fügen Sie dem ExposeHeaders Element in Ihrer CORS Konfiguration alle zulässigen Header hinzu, wie unten gezeigt.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1",
    "x-amz-meta-custom-header2"
]           

Überlegungen zu CORS S3-Proxy-Integrationen

Wenn bei Ihnen Fehler auftreten und Sie die CORS Konfiguration Ihres S3-Buckets bereits überprüft haben und die Cross-Origin-Anfrage an Proxys wie gesendet wird AWS CloudFront, versuchen Sie Folgendes:

Einige Proxys bieten vordefinierte Funktionen für Anfragen. CORS In können Sie beispielsweise eine Richtlinie konfigurieren CloudFront, die die Header enthält, die CORS Anfragen ermöglichen, wenn der Ursprung ein S3-Bucket ist. Weitere Informationen finden Sie unter Steuern von Ursprungsanfragen mit einer Richtlinie und Verwenden von Richtlinien für verwaltete Ursprungsanfragen im CloudFront Entwicklerhandbuch.