Konfiguracja Nginx dla aplikacji jednostronicowej z pamięcią podręczną HTML5

Question

Próbuję zbudować pojedynczą aplikację strony, która będzie korzystać z pamięci podręcznej aplikacji HTML5, która będzie buforować całą nową wersję aplikacji dla każdego odrębnego adresu URL, dlatego muszę przekierować wszystkich do / i moja aplikacja będzie je potem trasować (jest to rozwiązanie używane na devdocs.io).

Oto moja konfiguracja nginx. Chcę, aby wszystkie żądania wysłały plik, jeśli istnieje, przekierowuję do mojego interfejsu API pod numer /auth i /api i przekierowuję wszystkie inne żądania do index.html. Dlaczego poniższa konfiguracja powoduje, że moja przeglądarka mówi, że istnieje pętla przekierowania? Jeśli użytkownik trafi blokadę nr 2, a jego trasa nie pasuje do pliku statycznego, jest on wysyłany do bloku lokalizacji nr 3, który przekieruje go do "/", który powinien trafić blok lokalizacji nr 1 i służyć index.html, prawda? Co powoduje tutaj pętlę przekierowania? Czy istnieje lepszy sposób na osiągnięcie tego?

root /files/whatever/public; 
index index.html; 

# If the location is exactly "/", send index.html. 
location =/{ 
    try_files $uri /index.html; 
} 

location/{ 
    try_files $uri @redirectToIndex; 
} 

# Set the cookie of the initialPath and redirect to "/". 
location @redirectToIndex { 
    add_header Set-Cookie "initialPath=$request_uri; path=/"; 
    return 302 $scheme://$host/; 
} 

# Proxy requests to "/auth" and "/api" to the server. 
location ~* (^\/auth)|(^\/api) { 
    proxy_pass http://application_upstream; 
    proxy_redirect off; 
} 

Answer 1

Ten komunikat wskazuje, że pętla /files/whatever/public/index.html nie istnieje, więc try_files w miejscu/nie znajdzie $ uri gdy jest równa /index.html, więc try_files zawsze wewnętrznie przekierowuje te żądania do @ lokalizacji, która wykonuje zewnętrzne przekierowanie.

Jeśli nie masz bardziej skomplikowanej konfiguracji niż opisałeś, nie sądzę, że musisz zrobić tak wiele. Nie powinieneś potrzebować zewnętrznych przekierowań (lub nawet przekierowań wewnętrznych) lub wysyłania plików cookie po stronie serwera dla aplikacji JS. Dopasowanie do wyrażenia regularnego dla aplikacji i interfejsu API również nie było odpowiednie.

root /files/whatever/public; 
index index.html; 

location/{ 
    try_files $uri /index.html =404; 
} 

# Proxy requests to "/auth" and "/api" to the server. 
location ~ ^/(auth|api) { 
    proxy_pass http://application_upstream; 
    proxy_redirect off; 
}