Zapobiegaj przekierowaniu Xmlhttprequest

112

Czy można uniemożliwić przeglądarce podążanie za przekierowaniami podczas wysyłania XMLHttpRequest-s (tj. Aby odzyskać kod stanu przekierowania i samodzielnie go obsłużyć)?

javascript ajax xmlhttprequest

— Zim
źródło

102

Niezgodne ze standardem W3C dla obiektu XMLHttpRequest (podkreślenie dodane):

Jeśli odpowiedź jest przekierowaniem HTTP:

Jeśli pochodzenie adresu URL przekazanego przez nagłówek lokalizacji jest tym samym źródłem co źródło XMLHttpRequest, a przekierowanie nie narusza środków ostrożności dotyczących nieskończonej pętli, postępuj zgodnie z przekierowaniem , obserwując reguły zdarzeń żądań tego samego źródła.

Zastanawiali się nad tym w przyszłej wersji:

Niniejsza specyfikacja nie obejmuje następujących funkcji, które są rozważane w przyszłej wersji tej specyfikacji:

Właściwość, aby wyłączyć następujące przekierowania;

ale najnowsza specyfikacja już o tym nie wspomina.

— Boy Baukema
źródło

5

Śmieszne jest, gdy przezroczyste przekierowanie polega na nadpisaniu niektórych nagłówków HTTP, które zostały ustawione w pierwotnym żądaniu. W szczególności, jeśli nagłówek „Accept” został ustawiony na określony typ zawartości, Firefox nie umieści tego nagłówka podczas wykonywania przekierowania (co utrudnia tworzenie w pełni opartych na REST usług internetowych, które używają tego nagłówka ... narzekać).

— ruquay

1

Dalsze poszukiwania przyniosły mi ten raczej stary raport o błędzie: bugzilla.mozilla.org/show_bug.cgi?id=401564

— ruquay

2

Zgadzam się, całkowicie rediculus wada projektowa.

— Rasive

35

Nowy Fetch api obsługuje różne tryby postępowania przekierowania: follow, error, i manual, ale nie mogę znaleźć sposób, aby zobaczyć nowy adres URL lub kod statusu przekierowania, gdy został odwołany. Możesz po prostu zatrzymać samo przekierowanie, a wtedy wygląda to na błąd (pusta odpowiedź). Jeśli to wszystko, czego potrzebujesz, możesz iść. ~~Należy również pamiętać, że żądań wysyłanych za pośrednictwem tego interfejsu API nie można jeszcze anulować .~~ Oni są teraz.

Jeśli chodzi o XMLHttpRequest, możesz HEADserwer i sprawdzić, czy adres URL się zmienił:

var http = new XMLHttpRequest();
http.open('HEAD', '/the/url');
http.onreadystatechange = function() {
    if (this.readyState === this.DONE) {
        console.log(this.responseURL);
    }
};
http.send();

Nie otrzymasz kodu statusu, ale znajdziesz nowy adres URL bez pobierania z niego całej strony.

— użytkownik
źródło

Czasami użycie OPTIONSmoże być lepszym wyborem, w każdym razie działa tylko do celów nieogólnych itp. Administrator skonfigurował przekierowanie całej witryny / schematu, na przykład HTTP -> HTTPS

— William Leung

12

Możesz użyć responseURLwłaściwości, aby uzyskać miejsce docelowe przekierowania lub sprawdzić, czy odpowiedź została ostatecznie pobrana z zaakceptowanej lokalizacji.
To oczywiście oznacza, że wynik i tak jest pobierany, ale przynajmniej możesz uzyskać niezbędne informacje o miejscu docelowym przekierowania i na przykład wykryć warunki, w których chcesz odrzucić odpowiedź.

— Roland Pihlakas
źródło

Nie działa w IE developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/ ...

— HMR

11

Nie, nie ma żadnego miejsca w interfejsie API udostępnianym przez XMLHttpRequest, które pozwala na zastąpienie domyślnego zachowania automatycznego śledzenia 301 lub 302.

Jeśli klient korzysta z IE w systemie Windows, możesz zamiast tego użyć WinHTTP, aby ustawić opcję zapobiegającą temu zachowaniu, ale jest to bardzo ograniczające rozwiązanie.

— AnthonyWJones
źródło