AWS CloudFront zwraca http 307, gdy pochodzenie jest wiadrem S3

Utworzyłem wiadro s3 z niektórymi plikami. Stworzyłem dystrybucję CloudFront z tym wiadrem S3 jako źródłem i zmieniłem status na wdrożony.AWS CloudFront zwraca http 307, gdy pochodzenie jest wiadrem S3

Kiedy zwijają CloudFront dla każdego pliku otrzymuję:

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

Kiedy ta moja S3 wiadra dla każdego pliku I Get That zawartość pliku.

Co robię źle? Jak zmusić chmurę do przechowywania plików w pamięci podręcznej, aby klienci nie musieli pobierać danych bezpośrednio z S3?

Źródło

2016-08-01 user3231055

Czy wypróbowałeś Curl natychmiast po otrzymaniu wysłanej wiadomości? – error2007s

@ error2007s ponad 3 godziny został wdrożony, ale komunikat nadal występuje – user3231055

W jakim regionie jest twoje wiadro? Jaki jest twój punkt końcowy, który podałeś w swojej dystrybucji CloudFront? –

Thx Matt Houser z komentarza do mojego pierwszego posta!

Wygląda na to, że CloudFront buforował moje pierwsze żądania do plików, gdy dystrybucja nie była w pełni gotowa (ale była w stanie wdrożonym w tym czasie, więc uważaj!). Poprosiłem o unieważnienie wszystkich plików, które były w pamięci podręcznej, zajęło to kilka minut, ale po unieważnieniu zostało zrobione, wszystkie pliki zostały zwinięte z http 200 za pomocą adresu URL CloudFront.

Problemem stało się jasne po komentarzu od Michael-sqlbot:

Wszystkie łyżki posiadają przynajmniej dwie REST końcowych hostów. W eu-west-1, są to example-bucket.s3-eu-west-1.amazonaws.com i przyklad-bucket.s3.amazonaws.com. Pierwsza będzie natychmiastowa ważna po utworzeniu kubełka. Drugi - czasem nazywany jako "globalny punkt końcowy" - który jest tym, którego CloudFront używa - , nie będzie, chyba że wiadro znajduje się w nas-wschód-1. Przez kilka sekund minut, zmienne według lokalizacji i innych czynników, staje się globalnie dostępne również pod numerem . Wcześniej zwrócono 307 przekierowanie: . Dlatego wiadro nie było gotowe.

Źródło

2016-08-01 21:24:02 user3231055

W rzeczywistości nie była to * dystrybucja *, która nie była w pełni gotowa. Gdyby nie był gotowy, nie działałby. [To było * wiadro *, które nie było gotowe] (http://docs.aws.amazon.com/AmazonS3/latest/dev/Redirects.html). Tymczasowe przekierowania są normalne przez pierwsze kilka minut życia nowego wiadra, czasem trochę dłużej, gdy wiadro nie znajduje się w regionie us-east-1, ze względu na sposób działania globalnego punktu końcowego DNS. Odpowiedzi podawane z pamięci podręcznej przez CloudFront również mają nagłówek "Wiek:", co sugerowałoby, że to, co widzisz, było buforowane. –

@ Michael-sqlbot Co masz na myśli pod wiadro nie było gotowe? Kręciło się normalnie, a nie w tym samym czasie w zachmurzeniu. – user3231055

Wszystkie segmenty mają co najmniej dwa nazwy hosta punktu końcowego usługi REST. W eu-west-1 są to example-bucket.s3-eu-west-1.amazonaws.com i example-bucket.s3.amazonaws.com. Pierwsza będzie poprawna, gdy zostanie utworzony wiadro. Drugi - czasem określany jako "globalny punkt końcowy" - który jest wykorzystywany przez CloudFront - nie będzie, chyba że wiadro jest w nas - na wschodzie-1. Przez okres od sekund do minut, zależnie od lokalizacji i innych czynników, staje się globalnie dostępny. Wcześniej zwracane jest przekierowanie 307. Dlatego wiadro nie było gotowe. –

AWS CloudFront zwraca http 307, gdy pochodzenie jest wiadrem S3

Odpowiedz

Powiązane problemy