2016-08-01 33 views
14

Ich habe den s3-Bucket mit einigen Dateien erstellt. Ich habe die CloudFront-Distribution mit diesem S3-Bucket als Ursprung erstellt und den Status in "Bereitgestellt" geändert.AWS CloudFront gibt HTTP 307 zurück, wenn der Ursprung S3-Bucket ist

Wenn ich Cloudfront für jede Datei kräuseln ich:

<Error><Code>TemporaryRedirect</Code><Message>Please re-send this request to the specified temporary endpoint. Continue to use the original request endpoint for future requests.</Message><Bucket>MY-BUCKET</Bucket><Endpoint>MY-BUCKET.s3-eu-west-1.amazonaws.com</Endpoint><RequestId>...</RequestId><HostId>...</HostId></Error> 

Wenn ich meine S3 Eimer für jede Datei, die ich, dass die Dateiinhalte erhalten kräuseln.

Was mache ich falsch? Wie kann Cloudfront gezwungen werden, Dateien zwischenzuspeichern, damit Clients nicht direkt Daten von S3 abrufen müssen?

+0

Haben Sie die Curl sofort getestet, als Sie die bereitgestellte Nachricht erhalten haben? – error2007s

+0

@ error2007s mehr als 3 Stunden es ist im Einsatz, aber die Nachricht bleibt bestehen – user3231055

+0

In welcher Region ist Ihr Eimer? Was ist Ihr Bucket-Endpunkt, den Sie in Ihrer CloudFront-Verteilung angegeben haben? –

Antwort

22

Thx Matt Houser von Kommentar zu meinem ersten Beitrag!

Es scheint, CloudFront cached meine ersten Anforderungen an Dateien, wenn die Verteilung nicht vollständig bereit war (aber es war zu dieser Zeit im bereitgestellten Zustand, also Vorsicht!). Ich forderte die Ungültigmachung für alle Dateien, die sich im Cache befanden, es dauerte einige Minuten, aber nach der Ungültigkeitserklärung wurden alle Dateien mit http 200 unter Verwendung der CloudFront-URL gelockt.

Das Problem wurde klar, nach dem Kommentar von Michael-sqlbot:

Alle Schaufeln haben mindestens zwei REST-Endpunkt Host-Namen. In eu-west-1, sind dies beispiel-bucket.s3-eu-west-1.amazonaws.com und beispiel-bucket.s3.amazonaws.com. Die erste wird sofort gültig sein, wenn der Bucket erstellt wird. Der zweite - manchmal als bezeichnet - als der "globale Endpunkt" - der CloudFront verwendet - wird nicht, es sei denn, der Bucket ist in us-east-1. Über einen Zeitraum von Sekunden zu Minuten, variabel nach Standort und anderen Faktoren, wird es global ebenfalls zugänglich . Vorher ist die 307-Weiterleitung zurückgegeben. Daher war der Eimer nicht bereit.

+3

Eigentlich war es nicht die * Distribution *, die nicht komplett fertig war. Wenn es nicht fertig gewesen wäre, hätte es nicht funktioniert. [Es war der * Eimer *, der nicht bereit war] (http://docs.aws.amazon.com/AmazonS3/latest/dev/Redirects.html). Temporäre Redirects sind normal für die ersten paar Minuten des Lebens eines neuen Buckets, manchmal ein wenig länger, wenn sich der Bucket nicht in der Region us-east-1 befindet, weil der globale Endpunkt DNS funktioniert. Antworten, die von CloudFront aus dem Cache bereitgestellt werden, haben auch einen 'Age:' - Header, der darauf hindeutet, dass das, was Sie gerade sehen, zwischengespeichert wurde. –

+0

@ Michael-sqlbot was meinst du unter dem Eimer war nicht bereit? Es war normal und Cloudfront nicht gleichzeitig gerollt. – user3231055

+1

Alle Buckets haben mindestens zwei Hostnamen für REST-Endpunkt. In eu-west-1 sind dies beispiel-bucket.s3-eu-west-1.amazonaws.com und beispiel-bucket.s3.amazonaws.com. Die erste wird sofort gültig sein, wenn der Bucket erstellt wird. Der zweite - manchmal auch als "globaler Endpunkt" bezeichnet - der von CloudFront verwendet wird - wird nicht ausgeführt, es sei denn, der Bucket befindet sich in us-east-1. Über einen Zeitraum von Sekunden bis Minuten, variabel nach Standort und anderen Faktoren, wird es auch global zugänglich. Vorher wird die 307-Weiterleitung zurückgegeben. Daher war der Eimer nicht bereit. –