„UWAGA: wyświetlane są tymczasowe nagłówki” w debuggerze Chrome

Zauważyłem dziwny komunikat ostrzegawczy podczas przeglądania pobranych zasobów za pomocą Google Chrome Inspector ( F12):

Uwaga pokazane są tymczasowe nagłówki

Znalazłem coś, co może być istotne, Panel sieci: dodaj ostrożność do tymczasowych nagłówków wniosków , ale nie mogłem tego w pełni zrozumieć. Podobne pytania można znaleźć w żądaniach blokowania Chrome, a XMLHttpRequest nie może się załadować. Nieobciążone zasoby pokazują ostrożność: wyświetlane są tymczasowe nagłówki .

Podobnie jak w pierwszym pytaniu , mój zasób został zablokowany, ale później automatycznie załadował ten sam zasób. W przeciwieństwie do drugiego pytania , nie chcę niczego naprawiać; Chcę wiedzieć, co oznacza ta wiadomość i dlaczego ją otrzymałem.

Zasób może być blokowany przez rozszerzenie (w moim przypadku AdBlock).

Wiadomość jest dostępna, ponieważ nigdy nie wysłano żądania odzyskania tego zasobu, więc wyświetlane nagłówki nie są prawdziwe. Jak wyjaśniono w podanym przez Ciebie problemie, prawdziwe nagłówki są aktualizowane, gdy serwer odpowiada, ale nie ma odpowiedzi, jeśli żądanie zostało zablokowane.

Znalazłem informacje o rozszerzeniu, które blokowało mój zasób, za pomocą narzędzia net-internals w Chrome:

Dla najnowszych wersji chrome

• Wpisz chrome://net-export/pasek adresu i naciśnij Enter.
• Rozpocznij nagrywanie. I zapisz plik nagrania do lokalnego.
• Otwórz stronę z problemami.
• Wróć do net-internals
• Możesz wyświetlić plik zarejestrowanego dziennika tutaj https://netlog-viewer.appspot.com/#import
• kliknij zdarzenia (###) i użyj pola tekstowego, aby znaleźć zdarzenie związane z zasobem (użyj części adresu URL).
• Na koniec kliknij wydarzenie i sprawdź, czy wyświetlone informacje coś Ci mówią.

Dla starszych wersji chrome

• Wpisz chrome://net-internalspasek adresu i naciśnij Enter.
• Otwórz stronę z problemami.
• Wróć do net-internals, kliknij zdarzenia (###) i użyj pola tekstowego, aby znaleźć zdarzenie związane z zasobem (użyj części adresu URL).
• Na koniec kliknij wydarzenie i sprawdź, czy wyświetlone informacje coś Ci mówią.

Wierzę, że dzieje się tak, gdy faktyczne żądanie nie zostanie wysłane. Zwykle dzieje się to, gdy ładujesz buforowany zasób.

W przypadku Chrome v72 + rozwiązaniem tego było dla mnie tylko to:

przejdź do chrome://flags/i wyłącz te 3 flagi

• Wyłącz izolację witryny
• Włącz usługę sieciową
• Uruchamia usługę sieciową w toku

lub możesz to zrobić z wiersza poleceń:

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

dlaczego tak się dzieje

Wygląda na to, że Google przekształca silnik Chromium w modułową strukturę, w której różne usługi zostaną podzielone na samodzielne moduły i procesy. Nazywają to serwisowaniem procesu. Pierwszym krokiem jest usługa sieciowa, usługa interfejsu użytkownika, usługa tożsamości i usługa urządzenia. Google udostępnia oficjalne informacje na stronie projektu Chromium .

czy zmiana tego jest niebezpieczna?

Przykładem jest praca w sieci: gdy już mamy usługę sieciową, możemy ją uruchomić poza procesem dla lepszej stabilności / bezpieczeństwa lub w trakcie procesu, jeśli jesteśmy ograniczeni zasobami . źródło

Napotkałem ten problem i udało mi się zidentyfikować konkretną przyczynę, o której nie wspomniano powyżej ani w odpowiedziach, ani w pytaniu.

Korzystam z pełnego stosu js, kątowego frontu i zaplecza węzła na SSL, a interfejs API znajduje się w innej domenie działającej na porcie 8081, więc wykonuję żądania CORS i poświadczenia przy usuwaniu pliku cookie sesji z interfejsu API

Tak konkretnie mój scenariusz brzmiał: żądanie POST, przy użyciu poświadczeń do portu 8081, spowodowało wyświetlenie komunikatu „UWAGA: tymczasowe nagłówki są wyświetlane” w inspektorze, a także zablokowanie żądania.

Moim rozwiązaniem było skonfigurowanie apache do przekazywania proxy ze zwykłego portu SSL 443 do portu SSL węzła 8081 (węzeł musi znajdować się na wyższym porcie, ponieważ nie można go uruchomić jako root w prod). Chyba więc Chrome nie lubi żądań SSL do niekonwencjonalnych portów SSL, ale być może ich komunikat o błędzie może być bardziej szczegółowy.

Może się to również zdarzyć (tylko w przypadku żądań krzyżowych) z powodu nowej funkcji zwanej izolacją witryny

Ta strona zawiera szczegółowe informacje na temat problemu i obejścia tego problemu . W tym celu należy przejść do chrome://flags/#site-isolation-trial-opt-outchrome i zmienić to ustawienie na „Rezygnacja” i ponownie załadować chrome.

To znany problem . Jednak ta strona mówi, że jest naprawiona w chrome 68, ale używam chrome 68 i nadal mam problem.

Przesyłane zasoby HTTP / 2 zostaną wygenerowane Provisional headers are shownprzez inspektora zgodnie z tą samą teorią, co @wvega opublikowany w jego odpowiedzi powyżej .

np .: Ponieważ serwer przekazał zasoby klientowi ( zanim klient o nie poprosił ), przeglądarka ma zasoby w pamięci podręcznej i dlatego klient nigdy nie wysyła / nie potrzebuje żądań; Więc ponieważ...

... prawdziwe nagłówki są aktualizowane, gdy serwer odpowiada, ale nie ma odpowiedzi, jeśli żądanie zostało zablokowane.

Moja sytuacja dotyczy różnych źródeł .
Sytuacja: przeglądarka wysyła OPTIONSżądanie przed wysłaniem prawdziwego żądania, takiego jak GETlub POST. Deweloper zaplecza zapomina poradzić sobie z OPTIONSżądaniem, pozwalając mu przejść przez kod usługi, co powoduje, że czas przetwarzania jest zbyt długi. Dłuższy niż limit czasu, który napisałem podczas axiosinicjalizacji, czyli 5000 milisekund. Dlatego nie można wysłać prawdziwego żądania, a następnie napotkałem provisional headers are shownproblem.
Rozwiązanie: Jeśli chodzi o OPTIONSżądanie, backend API po prostu zwraca wynik, sprawia, że ​​żądanie jest szybsze, a prawdziwe żądanie może zostać wysłane przed upływem limitu czasu.

Wątpię, by moja odpowiedź była na czas, aby ci pomóc, ale inni mogą uznać ją za pomocną. Wystąpił podobny problem ze skryptem jQuery Ajax Post, który utworzyłem.

Okazało się, że miałem literówkę w atrybucie href znacznika A, którego użyłem do odpalenia posta. Wpisałem href = " javacsript:; " (odwrócenie „s” i „c”) .. spowodowało to, że skrypt próbował odświeżyć stronę, gdy post próbował uruchomić. poprawiłem literówkę i działało to dla mnie idealnie.

Ten komunikat może wystąpić, gdy witryna jest chroniona za pomocą HSTS . Następnie, gdy ktoś łączy się z wersją URL adresu URL, przeglądarka zgodnie z instrukcją HSTS nie wysyła żądania HTTP, ale wewnętrznie bezpiecznie przekierowuje do zasobu HTTPS. Ma to na celu uniknięcie ataków obniżających standard HTTPS, takich jak sslstrip .

Może tak być, ponieważ wysłałeś żądanie Ajax, jednocześnie przeskakujesz swoją stronę na inną za pomocą location.href lub czegoś podobnego. Poprzednie żądanie nie powiodło się.

Ten komunikat ostrzegawczy pojawia się również, jeśli odpowiedź jest nieprawidłowa i dlatego została odrzucona przez przeglądarkę.

W moim przypadku żądanie zostało poprawnie wysłane do serwera, kod po stronie serwera następnie wygenerował błąd, a moja niestandardowa obsługa błędów zwróciła komunikat o błędzie w polu komunikatu o stanie HTTP. Ten błąd nie został jednak odebrany po stronie klienta z powodu nieprawidłowych znaków w komunikacie o błędzie (opisanym tutaj http://aspnetwebstack.codeplex.com/workitem/1386 ), co spowodowało uszkodzenie nagłówków odpowiedzi.

Natrafiłem na ten problem z wywołaniem AJAX, które nigdy się nie zakończy. Postępowałem zgodnie z radą i wskazówkami wvega na temat debugowania, chrome://net-internalsaby ostatecznie ustalić inną clickprocedurę obsługi zdarzeń na stronie, nasłuchując w węźle nadrzędnym, powodując, że przeglądarka przechodziła do tego samego adresu URL (więc nie było to łatwo zauważalne).

Rozwiązaniem było dodanie event.stopPropagation()w clickprzewodnika na formularzu przycisk Prześlij, aby utrzymać kliknięcie od propagacji aż DOM i anulowanie żądania AJAX w toku (zainicjowane przez submitprzewodnika po form).

Ostatnio pojawiło się to (tak naprawdę dzisiaj), gdy wywołałem połączenie AJAX na serwer, a Chrome odpala „Uwaga: wyświetlane są tymczasowe nagłówki”. W skryptach PHP po stronie serwera istnieją zapytania MySQL, które mogą być niemal natychmiastowe lub zająć kilka sekund, w zależności od danego scenariusza. Moja odpowiedź serwera nie jest wysyłana z powrotem do przeglądarki, dopóki zapytania nie zostaną zakończone. Odkryłem, że ten błąd pojawia się tylko wtedy, gdy wykonywane są czasochłonne zapytania (w sumie do kilku sekund), co uniemożliwia odesłanie odpowiedzi.

Mój scenariusz dotyczy bardzo rzadkiej możliwości zmiany tabeli przez dodanie / usunięcie setek kolumn dla danych wyjściowych modelu pogody ... stąd opóźnienie odpowiedzi od iteracji przez pętlę zapytań ALTER TABLE.

Częstym powodem jest to, że śledzisz zdarzenie i nie zapobiegasz domyślnemu działaniu. Na przykład, jeśli masz zdarzenie kliknięcia, będziesz chciał dołączyć:

e.preventDefault();

lub

return false;

Jeśli tego nie zrobisz, zobaczysz tymczasowe ostrzeżenie oraz status „anulowany” na karcie Sieć konsoli internetowej.

W moim przypadku była to tylko fałszywa ścieżka do zasobu (svg / img)

Ten problem wystąpił, gdy wysyłałem nieprawidłowy nagłówek autoryzacji HTTP. Zapomniałem zakodować go w base64.

Natknąłem się na to i zniknęło, kiedy przestawiłem się z https na http. Certyfikaty SSL, których używamy w dev, nie są weryfikowane przez firmę zewnętrzną. Są tylko lokalnie generowanymi certyfikatami programistycznymi.

Te same połączenia działają dobrze w Chrome Canary i Firefox. Te przeglądarki nie wydają się być tak rygorystyczne w stosunku do certyfikatu SSL, jak Chrome. Połączenia nie powiedzie się w Chrome z komunikatem „UWAGA: Tymczasowe nagłówki ...”.

Myślę / mam nadzieję, że kiedy użyjemy legalnego certyfikatu SSL na etapie i prod, nie zobaczymy już tego zachowania w Chrome.

Wrzucam tylko dwa centy. Piszę aplikację sieci Web przy użyciu żądań CORS i pełnej usługi sieci Web RESTful. Przekonałem się, że chrome zgłasza ten błąd, gdy mam nieobsługiwany wyjątek lub zgłoszony błąd PHP. Wystarczy, że ktoś inny napotka problem. Zauważyłem, że kiedy to się stanie, mogę uruchomić aplikację Chrome „Postman - Rest Client” i uruchomić dokładnie to samo żądanie, ale w aplikacji Chrome dostanę błąd PHP zamiast tego nieopisowego błędu.

Wystąpił ten problem, gdy próbowałem załadować plik main.js z wymaganiem js po raz drugi po wprowadzeniu zmian w wyniku błędu. Właśnie włączyłem w ustawieniach Narzędzi programisty „Wyłącz pamięć podręczną (gdy DevTools jest otwarty)”. i to uroku.

Kolejny możliwy scenariusz, który widziałem - dokładnie to samo żądanie jest wysyłane ponownie po kilku milisekundach (najprawdopodobniej z powodu błędu po stronie klienta).
W takim przypadku zobaczysz również, że status pierwszego żądania jest „anulowany”, a opóźnienie wynosi tylko kilka milisekund.

Działo się to dla mnie, kiedy miałem link do pobrania i po kliknięciu go próbowałem również złapać kliknięcie za pomocą jquery i wysłać żądanie ajax. Problem polegał na tym, że po kliknięciu linku do pobrania opuszczasz stronę, nawet jeśli tak nie wygląda. Jeśli nie byłoby transferu plików, zobaczysz żądaną stronę. Ustawiłem więc cel = "_ puste", aby zapobiec temu problemowi.

Wystąpił ten błąd, gdy próbowałem wydrukować stronę w wyskakującym okienku. Okno dialogowe drukowania zostało wyświetlone i wciąż czeka na moją akceptację lub anulowanie drukowania w wyskakującym okienku, podczas gdy na stronie wzorcowej również czekał w tle z komunikatem OSTROŻNIE wyświetlane są tymczasowe nagłówki gdy próbowałem kliknąć inny link.

W moim przypadku rozwiązaniem było usunięcie window.print ();skryptu, który wykonywał w <body>wyskakującym oknie, aby zapobiec wyświetlaniu okna dialogowego.

Widziałem to, gdy liczba połączeń z moim serwerem przekroczyła maksymalny limit połączeń na serwer wynoszący 6 Chrome.

Użyj tej pięści kodu swojego kodu:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

To działa dla mnie.

Oto inne rozwiązanie.

Jeśli napotkasz ten problem z wywołaniem $ ajax (), dodaj, http://zanim serwer server rozwiąże problem.

var requestURL = "http://" + serverHost;
$.ajax({
    dataType: "json",
    url: requestURL,
    data: data,
    success: success    
});

Jeśli tworzysz aplikację Asp.Net Mvc i próbujesz zwrócić a JsonResultw kontrolerze, upewnij się, że dodajesz JsonRequestBehavior.AllowGetdo Jsonmetody. To naprawiło to dla mnie.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

Komunikat „Uwaga: wyświetlane są tymczasowe nagłówki”, gdy witryna hostowana na HTTPS wywołuje połączenia z WebApi hostowane na HTTP. Możesz sprawdzić wszystko, czy wszystkie twoje API są HTTPS. Przeglądarka uniemożliwia wywołanie niezabezpieczonego zasobu. Możesz zobaczyć podobną wiadomość w swoim kodzie, gdy używasz FETCH API do domeny z HTTP.

Zawartość mieszana: strona „ https://website.com ” została załadowana przez HTTPS, ale zażądała niezabezpieczonego zasobu „ http://webapi.com ”. To żądanie zostało zablokowane; treść musi być obsługiwana przez HTTPS.

Miałem podobny problem z aplikacją MEAN. W moim przypadku problem występował tylko w jednym żądaniu get. Próbowałem usunąć adblock, wyczyścić pamięć podręczną i spróbować z różnymi przeglądarkami. Nic nie pomogło.

w końcu zorientowałem się, że interfejs API próbował zwrócić ogromny obiekt JSON. Kiedy próbowałem wysłać mały obiekt, działał dobrze. Na koniec zmieniłem implementację, aby zwracała bufor zamiast JSON.

Chciałbym, aby expressJS zgłosił błąd w tym przypadku.

Ten problem występuje również podczas korzystania z niektórych pakietów, takich jak webpack-hot-middlewarei otwieranie wielu stron jednocześnie. webpack-hot-middlewareutworzy połączenie dla każdej strony w celu odsłuchania zmian kodu, a następnie odświeżenia strony. Każda przeglądarka ma max-connections-per-serverograniczenie, które wynosi 6 dla Chrome, więc jeśli otworzyłeś już więcej niż 6 stron w Chrome, nowe żądanie zostanie zawieszone, dopóki nie zamkniesz niektórych stron.

W moim przypadku przyczyną było rozszerzenie AdBlock.

Wysłano żądanie do serwera i otrzymałem odpowiedź, ale nie widziałem żądania plików cookie z powodu „Tymczasowych nagłówków ..” wyświetlanych w narzędziach programistycznych. Po wyłączeniu AdBlocka dla witryny ostrzeżenie zniknęło, a narzędzia programistyczne ponownie zaczęły wyświetlać pliki cookie.

Aby zmiana zaczęła obowiązywać, konieczne było również zamknięcie narzędzi deweloperskich i odświeżenie strony