Chrome-anmodning siger "Foreløbige headere vises":
Første gang browseren sender denne anmodning, bliver anmodningen blokeret, og der modtages intet svar. Når browseren bliver bedt om at sende denne anmodning igen, vil browseren rapportere denne advarsel, hvis den samme forespørgsel ikke er blevet besvaret, så hvor vil problemet være?
Jeg stødte på det flere gange i projektet, og jeg vil introducere forskellige scenarier henholdsvis:
1. Foreløbige headere vises, når man tilgår browseren på alle klienter:
Sådan håndterer du det: Tjek siden, hvor anmodningen blev udløst, for at se, om formularindsendelsen og ajax-anmodningen bliver udløst samtidig.
For eksempel definerer du en knap, skriver den indsendt, og definerer en ajax-begivenhed for knappen;
Dette scenarie er et af dem, der er opstået i vores tidligere udviklingsproces
2. Nogle klientbrowsere optræder
Sådan håndterer du det: Kald Chromes chrome://net-internals/#events, genaktiver derefter anmodningen, og tjek derefter loggen over anmodninger, hvor Provisive-headere vises;
Se om delegate_blocked_by nøgleord findes; Dette skyldes som regel, at browser-plugin'et eller klientens software opsnapper anmodningen; Den situation, vi har, bliver opsnappet af WebSense Endpoint;
Hvis det er tilfældet, kan det grundlæggende ignoreres, klientens eget problem; Du kan overveje at afinstallere plugin'et eller softwaren og prøve igen for at se, om det stadig dukker op; Hvis det stadig forekommer, så se venligst, om det falder ind under følgende betingelser
3. Alle klienter har haft denne fejl tilfældigt og lejlighedsvis, og hvis det er tilfældet, er det ofte et serverproblem
Håndteringsmetode: Fejlfinding baseret på udrulningsarkitekturen. For eksempel er nogle nøgleprocesser i vores deploymentsarkitektur nginx----> gateway-applikation----> F5 load balancer----> applikationsserver (docker)
Du kan fejlfinde lag for lag, den enkle måde er direkte at skrive en for loop curl-anmodning med servershell-kommandoen og først kalde den lavest placerede applikationsserver (hvis du er bange for, at presset ikke er nok, kan du trykke den ned med flere tråde); Tryk op i rækkefølge; Under stresstesten kan du i realtid se, om anmodningen sidder fast; Hvis det findes, er det meget sandsynligt, at dette er problemet:
På nuværende tidspunkt har vi oplevet to situationer, den ene er på F5-niveau, hvor nogle forespørgsler mislykkes med load balances til applikationsserveren; Der er også en situation, hvor den sidder fast på nginx-niveauet;
Løsning: Load balance-strategien på F5-niveau er ændret fra performance L4 til standard.
Nginx-niveau fastlåst situationshåndteringsplan: Jeg har faktisk ikke deltaget i denne situation, og jeg forstår, at ændring af mange konfigurationer af nginx ikke har nogen effekt, og til sidst bare dræber og geninstallerer, så jeg fandt ikke det centrale punkt
Min egen løsning, fordi Fiddler 4 jeg bruger ikke er lukket normalt, så jeg åbnede Fiddler 4 igen, prøvede at anmode om hjemmesiden, og den vendte tilbage til normalt, på dette tidspunkt lukkede Fiddler 4 igen.
|
Opslået på 22/05/2018 22.57.55
|
|
|
|
