Chrome-forespørselen sier «Provisoriske headers vises»:
Første gang nettleseren sender denne forespørselen, blir forespørselen blokkert og det mottas ikke noe svar. Når nettleseren blir bedt om å sende denne forespørselen igjen, vil nettleseren rapportere denne advarselen hvis den samme forespørselen ikke har blitt besvart, så hvor vil problemet være?
Jeg støtte på det flere ganger i prosjektet, og jeg vil introdusere ulike scenarioer henholdsvis:
1. Foreløpige headers vises når man åpner nettleseren til alle klienter:
Hvordan håndtere det: Sjekk siden der forespørselen ble utløst for å se om skjemainnsending og ajax-forespørsel utløses samtidig.
For eksempel, definer en knapp, skriv er send, og definer en ajax-hendelse for knappen;
Dette scenariet er et av de som har oppstått i vår tidligere utviklingsprosess
2. Noen klientnettlesere dukker opp
Hvordan håndtere det: Ring Chromes chrome://net-internals/#events, utløs forespørselen på nytt, og sjekk deretter loggen over forespørsler hvor Provisive-headere vises;
Se om delegate_blocked_by nøkkelord finnes; Dette skyldes vanligvis at nettleserpluginen eller klientens programvare avlytter forespørselen; Situasjonen vi har blir avlyttet av WebSense Endpoint;
Hvis dette er tilfellet, kan det i praksis ignoreres, klientens eget problem; Du kan vurdere å avinstallere pluginen eller programvaren og prøve igjen for å se om det fortsatt vises; Hvis det fortsatt skjer, vennligst sjekk om det faller inn under følgende betingelser
3. Alle klienter har hatt denne feilen tilfeldig og av og til, og hvis dette er tilfelle, er det ofte et serversideproblem
Håndteringsmetode: Feilsøking basert på distribusjonsarkitekturen. For eksempel er noen nøkkelprosesser i vår distribusjonsarkitektur nginx----> gateway-applikasjon----> F5 lastbalanserer----> applikasjonsserver (docker)
Du kan feilsøke lag for lag, den enkle måten er å skrive en for loop curl-forespørsel direkte med servershell-kommandoen, og først kalle den laveste applikasjonsserveren (hvis du er redd for at presset ikke er nok, kan du trykke den ned med flere tråder); Press opp i tur; Under stresstesting kan du se i sanntid om forespørselen vil bli sittende fast; Hvis det finnes, er det svært sannsynlig at dette er problemet:
For øyeblikket har vi støtt på to situasjoner, den ene på F5-nivå, noen forespørsler blir mislykket lastbalansert til applikasjonsserveren; Det finnes også en situasjon hvor den sitter fast på nginx-nivå;
Løsning: Lastbalanseringsstrategien på F5-nivå er endret fra ytelsesnivå L4 til standard.
Nginx-nivå fastlåst situasjonshåndteringsplan: Jeg har faktisk ikke deltatt i denne situasjonen, og jeg forstår at det å endre mange konfigurasjoner av nginx ikke har noen effekt, og til slutt bare dreper og installerer på nytt, så jeg fant ikke hovedpoenget
Min egen løsning, fordi Fiddler 4 jeg bruker ikke er lukket normalt, så jeg åpnet Fiddler 4 på nytt, prøvde å be om nettsiden og den gikk tilbake til normalt, på dette tidspunktet lukket Fiddler 4 igjen.
|
Publisert på 22.05.2018 22:57:55
|
|
|
|
