Przeglądarka nie odświeża aplikacji Angular po wgraniu nowej wersji na serwer

Wgrywasz na serwer nową wersję aplikację Angular. Klient widzi starą wersję, bo przeglądarka cachuje index.html. Czy ktoś mierzył się z tym problemem?

Znalazłem przyczynę. Używam wtyczki jib-maven-plugin do budowania obrazów dockerowych. Wtyczka dba o to, aby każdy build miał ten sam hash, jeśli zawartość jest identyczna. Dlatego ustawia daty wszystkich plików na 1970. W konfiguracji nie ma opcji, aby zachować oryginalne daty.

A jeśli daty byłyby oryginalne, to skąd by one pochodziły?

Ale czy to by pomogło i przeglądarka za każdym razem by sprawdzała, czy jest nowa wersja?

Jaka jest praktyka we współczesnych aplikacjach?

Z serwera przychodzi:

• Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
• ETag: 3278434589

Nie ma nagłówka Cache-Control.

Ostatnio rzadko jest wysyłany Last-Modified, a raczej ETag (który się nie zmienia, bo index.html jest ten sam) lub Expires lub Cache-Control.

Potencjalnych rozwiązań jest kilka:

1. Cache-Control: no-cache lub must-revalidate dla index.html, a może dla wszystkich plików
2. Service Worker, co sprawdza, czy wyszła nowa wersja (używane m.in. w aplikacjach PWA)
3. ETag, ale jak go zmienić po wgraniu nowej wersji?
4. Inne pomysły?

Używany serwer HTTP to lighttpd. Nie musi być koniecznie ten.

A kiedy przeglądarka sprawdzi, czy są zmiany na serwerze, a kiedy wczyta wersję z pamięci podręcznej bez uderzenia do serwera?

Wysyłanie, bądź nie wysyłanie nagłówków, to rola serwera, albo jakiegoś gateway'a. Najprościej zmień daty plików i zobacz, czy przeglądarka sobie z tym poradzi. Przy statycznych plikach, leci tam więcej. W prawidłowo zaimplementowanym serwerze, przeglądarka wysyła informacje o dacie index.html, który leży w jej cache, serwer jeżeli posiada nowszą wersję, to ją zwraca, jeżeli nie posiada to odpowiada pustym 304 (nie mam nowszego). Nagłówek cache control jedynie informuje przeglądarkę, że bez względu na wszystko, ma sobie odświeżyć jakiś zasób nie rzadziej niż po podanym czasie.

--edit
Skoro wiesz, że problem leży w modyfikacjach dat plików serwowanych przez serwer, to przestań modyfikować daty.

A to jest ciekawe, bo jeśli zmieniają się hashe w nazwach plików .js, to index.html musi się zmienić. Widocznie przeglądarka nawet nie pyta serwera, czy jest nowa wersja. W takim razie trzeba to ogarnąć za pomocą Cache-Control lub innych nagłówków. Różne portale stosują różne podejścia.

A zerknąłeś w to co pokazuje zakłądka netwrok w przegądarce? Jeżeli przeglądarka nie ma w swoim cache jakiegoś pliku (a nie ma, bo nigdy go nie pobrała), to nie wysyła informacji o tym i serwer grzecznie zwraca o co go proszą. Jaki jest powód, dla którego zmieniasz te daty?

piotrpo napisał(a):

Jaki jest powód, dla którego zmieniasz te daty?

Napisałem na początku. Wtyczka, której używamy do budowania obrazów dockerowych, ustawia wszystkim plikom datę 1970 i nie da się tego wyłączyć. Ale gdyby data była inna, to pewnie i tak to by nie rozwiązało problemu. ETag powinien się zmieniać po zbudowaniu nowej wersji, bo zmieni się zawartość index.html (inne hashe plików .js). Stąd moje pytanie, jaka praktyka jest w branży, czy Cache-Control, czy inny mechanizm.

Użycie cache-control nie jest dobrym rozwiązaniem, bo to instrukcja dla przeglądarki, żeby albo nie korzystać z cache wcale (np. dyrektywa no-store), albo, żeby unieważniać cache po określonym czasie (max-age). To powoduje, że albo wyłączymy cache całkowicie i będziemy niepotrzebnie przesyłać dane.
Etag, tak jak piszesz powinien się zmieniać wraz ze zmianą treści, ale jak widać się nie zmienia.

Sprawdź, czy zmiana daty last modified na aktualną to zmieni. można to zrobić za pomocą touch plik. Jeżeli tak się stanie, to masz rozwiązanie.