HTTP 302 przekierowanie do wniosku Cors jest odrzucany przez przeglądarki

Question

wczytuję stronę HTML z niektórych javascript ze strony A.

Javascript wysyła żądanie HTTP GET do strony B. W tym momencie:
        - przeglądarka wysyła OPCJE żądać stronie B
        - Site B odpowiada OPCJE zażądać
        - przeglądarka wysyła ori Ginał żądanie HTTP GET do lokacji B
        - Site B odpowiada HTTP 302 z lokalizacją ustawioną na stronie C

W tym momencie przestaje Browser przetwarzania żądania. Spodziewałem się, że wyśle ​​żądanie HTTP OPTIONS do strony C, tak jak to zrobiło, gdy wysłało żądanie do strony B. Ale tak się nie stało. Podobne zachowanie zaobserwowałem w Firefoksie i Chrome.

Chciałbym zrozumieć, dlaczego przeglądarki zachowują się w ten sposób. Rozumiem, że powinny istnieć pewne kontrole lub maksymalne przekierowania, aby zapobiec pętlom, ale nie ograniczać 2 przekierowań.

Również dlaczego informacje z nagłówka NIE są wysyłane do kodu Javascript, aby aplikacja mogła coś z tym zrobić. Jest po prostu odrzucany przez przeglądarkę, chociaż dokucza Ci to, pokazując odpowiedź HTTP 302 z witryny C z adresem URL lokalizacji w konsoli przeglądarki.

XMLHttpRequest nie może załadować https://siteB/ ... Żądanie zostało przekierowane na "https://siteC/ ..", co jest niedozwolone dla żądań krzyżowych, które wymagają inspekcji wstępnej.

Wszelkie spostrzeżenia dotyczące projektu są szczerze doceniane.

Pozdrowienia

Answer 1

Cóż, miałem ten sam problem ty, i niestety, to zachowanie jest normalne, according to W3C spec

Ta specyfikacja opisuje zachowanie przeglądarki dotyczących CORS jak stan maszyny, a jeśli przejdź do kroku 3 (wykonując rzeczywistą prośbę), wyraźnie stwierdza:

To jest aktualna prośba. Zastosuj kroki make request i przestrzegaj poniższych reguł żądania podczas wysyłania żądania.

Jeśli odpowiedź ma kod statusu HTTP 301, 302, 303, 307 lub 308 Zastosuj kroki pamięci podręcznej i błędu sieciowego.

Więc jeśli dobrze rozumiem, nie możemy oczekiwać, że przeglądarka automatycznie zastosuje się do przekierowania w przypadku CORS (podobno, ponieważ OPCJA przyznała dostęp do innego zasobu?), Ale dlaczego nie automatycznie wysłać innej opcji? zażądać tego zasobu?).

Co gorsza, ponieważ nagłówki odpowiedzi są ukryte przez przeglądarkę po tym, jak automatyczne przekierowanie nie powiodło się z powyższego powodu, nie mamy dostępu do nagłówka Lokalizacja, aby samodzielnie obsłużyć kolejne wywołanie właściwego zasobu. Więc nie ma sposobu, aby pobrać rzeczywisty zasób w tym przypadku.

Uważam, że to błąd, ale nie mogłem znaleźć żadnego dobrego posta na ten temat w Internecie.

Jednym z obejść, o ile jest to możliwe, jest niewykonanie żądania CORS, a zamiast tego skorzystanie z prostego żądania (zgodnie ze specyfikacją, np. Prostego GET bez niestandardowych nagłówków), które nie spowoduje żadnych żądań wstępnych do wysłania: w tym przypadku przekierowanie działa normalnie (automatycznie następuje po przeglądarce).

W przeciwnym razie można zobaczyć, czy można dostroić serwer, aby nie odpowiadał na 302 w przypadku żądania typu CORS, ale zamiast tego odpowiadał niestandardowym kodem HTTP, który można zidentyfikować w kliencie, aby uwzględnić lokalizację przekierowania w treść odpowiedzi, aby Twój klient mógł wykonać to ręcznie.

Jeśli ktoś ma jakieś ważne informacje o tym, dlaczego takie zachowanie jest, proszę podać swój wkład :-)

Nadzieję, że to pomaga.