Zmuszając CloudFront do przekazania najnowszego pliku HTML z S3

tło

Prowadzę statyczną stronę na S3, z CloudFront na samej górze. Mam problem z moimi plikami HTML.

Zgodnie z FAQ CloudFront :

Amazon CloudFront używa tych nagłówków kontroli pamięci podręcznej, aby określić, jak często musi sprawdzać pochodzenie zaktualizowanej wersji tego pliku

Co zrobiłem do tej pory

Mając to na uwadze, ustawiłem pliki HTML w moim S3 Bucket, aby dodać następujące nagłówki:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Fri, 01 Jan 1990 00:00:00 GMT

Przy pierwszym połączeniu z moim samplefile.htmwidzę następujące nagłówki odpowiedzi (wykluczyłem oczywiste nagłówki (np. Content-Type), Aby przejść do sedna:

Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Date:Sat, 10 Dec 2011 14:16:51 GMT
ETag:"a5890ace30a3e84d9118196c161aeec2"
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT
Server:AmazonS3
X-Cache:Miss from cloudfront

Jak widać, mój Cache-Controlnagłówek jest tam. Problem polega na tym, że jeśli zaktualizuję ten plik i odświeżę, otrzymam buforowaną zawartość (a nie najnowszy plik) i widzę, że CloudFront obsługuje swoją buforowaną wersję, patrząc na nagłówki odpowiedzi:

X-Cache:Hit from cloudfront

Podsumowanie / pytanie

Mając powyższe na uwadze, jak mogę uzyskać automatyczne pobieranie najnowszego kodu HTML podczas korzystania z CloudFront?

Zgodnie z często zadawanymi pytaniami powinienem móc to zrobić za pomocą nagłówków Cache-Control, ale wydaje mi się, że to nie działa.

Po odpowiedziach poniżej

Ostatecznie zdecydowałem się zmienić moją stronę www CNAME, tak aby bezpośrednio wskazywała na mój segment S3. Następnie dodano nową CNAME o nazwie „static”, która wskazuje na CloudFront.

Oznacza to, że HTML jest bezpośrednio z S3, który następnie ma wszystkie swoje odwołania CSS / JS / IMG wskazujące na static.mydomain.com

Po pierwsze, Cloudfront ma na celu dostarczanie treści z pamięci podręcznej - jeśli spróbujesz serwować zawartość niebuforowaną z Cloudfront, jest to wolniejsze niż podawanie jej bezpośrednio z S3, w prawie wszystkich przypadkach (wyjątek stanowi coś takiego jak przesyłanie strumieniowe). Zastanów się przez chwilę, co musi się stać, aby wyświetlać zawartość z Cloudfront - trzeba ją pobrać z serwera źródłowego do lokalizacji, która jest geograficznie blisko użytkownika - co oznacza, że ​​w przypadku żądania, w którym Cloudfront musi pobrać zawartość z serwera źródłowego , dodajesz dodatkowe opóźnienie do żądania, a użytkownik odbiera zawartość wolniej. Tylko wtedy, gdy treść jest dostępna w skrajnej lokalizacji, kolejne żądania są szybsze.

Najlepszym podejściem do tego problemu jest zmiana nazw plików podczas aktualizacji strony - to zmusi Cloudfront do pobrania nowej zawartości. Ponownie pamiętaj, że Cloudfront jest zwykle używany do plików multimedialnych (w tym obrazów) i style / javascript - a nie do html. Zasadniczo będziesz mieć swój HTML na S3, a swoje obrazy na Cloudfront - przy każdej wprowadzonej zmianie możesz zmienić nazwę pliku na Cloudfront (np. File-v1.jpg, file-v2.jpg itp.). Innym powszechnym sposobem jest dołączenie ciągu zapytania z informacjami o wersji.

Należy również pamiętać, że Cloudfront nie obsługuje treści spakowanych gzipem - co może skutkować wolniejszą odpowiedzią niż ze zwykłego serwera (chociaż w twoim przypadku S3 również nie rozpoznaje przeglądarek obsługujących gzip).

Wreszcie, jeśli chcesz, możesz użyć unieważnienia, aby zmusić Cloudfront do odrzucenia istniejącej kopii i pobrania nowej z serwera źródłowego. Należy jednak pamiętać, że Cloudfront zapewnia tylko 1000 bezpłatnych unieważnień miesięcznie, po których koszt wynosi 0,005 USD / unieważnienie.

Najkrótszy czas, w którym Cloudfront będzie przechowywać zawartość, to 1 godzina , ale domyślnie 24 godziny. Dlatego postaram się ustawić maksymalny wiek na co najmniej 3600. Rozważ też nagłówek s-maxage (dla współdzielonych - tj. Treści proxy). Amazon zaleca ten samouczek buforowania.

Wystąpił niedawno problem , naprawiony kilka dni temu

Uważam, że dotychczasowe odpowiedzi, choć poprawne w tym czasie, są obecnie nieaktualne, ponieważ Cloudfront obsługuje teraz minimalny czas wygaśnięcia 0, a oryginalna próba OP użycia cache-age = 0 powinna teraz działać.

Chcesz się zastanowić, czy użyć tych innych nagłówków kontrolujących pamięć podręczną pod kątem tego, czy przyniosą oczekiwany rezultat - może być potrzebny tylko maksymalny wiek. Prawdopodobnie chcesz, aby Cloudfront sprawdził S3, aby sprawdzić, czy plik HTML się zmienił. Jeśli tak, Cloudfront może pobrać i zwrócić nowy plik. Jeśli nie, może obsługiwać klienta z istniejącej pamięci podręcznej (oszczędzając przepustowość S3 i obsługując klienta szybciej i bardziej lokalnie).

Chodzi o to, by Cloudfront udostępniał zawartość z pamięci podręcznej, tak, ale teraz obejmuje to treść, która czasami się zmienia, ale może być buforowana, jeśli się nie zmieniła.

Ciągi zapytań Ps również działają teraz z Cloudfront (jeśli skonfigurujesz „zachowanie” dla odpowiedniego źródła - kolejna nowa funkcja), jednak niektóre proxy mogą nadal nie buforować plików z ciągami zapytań.

Amazon Developer Guide: Expiration 1

Nie jestem pewien, jak CloudFront traktuje nagłówek tak jak Ty, ale jeśli nie określisz żadnych nagłówków, domyślny czas odświeżania obiektów to 24 godziny.

Jedną z rzeczy, które możesz zrobić, aby odświeżyć obiekty, jest unieważnienie zawartości. Sprawdź poniższy link, aby uzyskać więcej informacji. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html