Chrome-begäran säger "Provisoriska headers visas":
Första gången webbläsaren skickar denna förfrågan blockeras förfrågan och inget svar tas. När webbläsaren ombeds skicka denna förfrågan igen kommer webbläsaren att rapportera denna varning om samma föregående begäran inte har besvarats, så var kommer problemet att ligga?
Jag stötte på det flera gånger i projektet, och jag kommer att introducera olika scenarier respektive:
1. Preliminära headers visas när man går åt webbläsaren hos alla klienter:
Hur man hanterar det: Kolla sidan där begäran utlöstes för att se om formulärinlämningen och ajax-begäran triggas samtidigt.
Till exempel, definiera en knapp, skriva är submit, och definiera en ajax-händelse för knappen;
Detta scenario är ett av de som har uppstått i vår tidigare utvecklingsprocess
2. Vissa klientwebbläsare dyker upp
Hur man hanterar det: Anropa Chromes chrome://net-internals/#events, trigga sedan förfrågan igen och kontrollera sedan loggen över förfrågningar där provisoriska headers visas;
Se om delegate_blocked_by nyckelord finns; Detta beror vanligtvis på att webbläsarens plugin eller klientens mjukvara fångar upp förfrågan; Situationen vi har avlyssnas av WebSense Endpoint;
Om så är fallet kan det i princip ignoreras, klientens eget problem; Du kan överväga att avinstallera pluginet eller mjukvaran och försöka igen för att se om det fortfarande syns; Om det fortfarande förekommer, se om det omfattas av följande villkor
3. Alla klienter har haft detta fel slumpmässigt och ibland, och om så är fallet är det ofta ett serverproblem
Hanteringsmetod: Felsökning baserat på distributionsarkitekturen. Till exempel är några nyckelprocesser i vår distributionsarkitektur nginx----> gatewayapplikation----> F5 lastbalanserare----> applikationsserver (docker)
Du kan felsöka lager för lager, det enkla sättet är att direkt skriva en for loop curl-förfrågan med serverskalkommandot, och först anropa den lägsta applikationsservern (om du är rädd att pressen inte räcker kan du trycka ner den med flera trådar); Tryck upp i tur och ordning; Under stresstestningen kan du i realtid se om förfrågan fastnar; Om det hittas är det mycket sannolikt att detta är problemet:
För närvarande har vi stött på två situationer, en på F5-nivå, vissa förfrågningar är misslyckade med belastningsbalansering till applikationsservern; Det finns också en situation där den fastnar på nginx-nivån;
Lösning: Lastbalanseringsstrategin på F5-nivå har ändrats från prestandanivå L4 till standard.
Nginx-nivå fast situationshanteringsplan: Jag har faktiskt inte deltagit i den här situationen, och jag förstår att det inte har någon effekt att ändra många konfigurationer av nginx, och till slut bara döda och installera om, så jag hittade inte huvudpoängen
Min egen lösning, eftersom Fiddler 4 jag använder inte är stängd normalt, så jag öppnade Fiddler 4 igen, försökte begära webbplatsen och den återgick till normalt, då stängde jag Fiddler 4 igen.
|
Publicerad på 2018-05-22 22:57:55
|
|
|
|
