Die Chrome-Anfrage sagt "Provisorische Header werden angezeigt":
Beim ersten Senden dieser Anfrage durch den Browser wird die Anfrage blockiert und es kommt keine Antwort. Wenn der Browser erneut aufgefordert wird, diese Anfrage zu senden, meldet er diese Warnung, falls auf die vorherige Anfrage nicht beantwortet wurde, wo liegt also das Problem?
Ich bin im Projekt mehrmals darauf gestoßen und werde jeweils verschiedene Szenarien vorstellen:
1. Beim Zugriff auf den Browser aller Clients werden provisorische Header angezeigt:
Wie man damit umgeht: Überprüfe die Seite, auf der die Anfrage ausgelöst wurde, um zu sehen, ob die Einreichung des Formulars und die Ajax-Anfrage gleichzeitig ausgelöst werden.
Beispielsweise definiert man einen Button, tippt submit und definiert ein Ajax-Event für den Button;
Dieses Szenario ist eines derjenigen, die in unserem früheren Entwicklungsprozess entstanden sind
2. Einige Client-Browser erscheinen
Wie man damit umgeht: Rufen Sie Chromes chrome://net-internals/#events an, lösen Sie die Anfrage erneut aus und prüfen Sie anschließend das Logbuch der Anfragen, in denen Provisorische Header angezeigt werden;
Prüfen Sie, ob delegate_blocked_by Schlüsselwörter existieren; Dies liegt in der Regel daran, dass das Browser-Plug-in oder die Software des Clients die Anfrage abfängt; Die Situation, die wir haben, wird von WebSense Endpoint abgefangen;
Wenn das der Fall ist, kann es im Grunde ignoriert werden, also das eigene Problem des Kunden; Du kannst in Erwägung ziehen, das Plugin oder die Software zu deinstallieren und es erneut zu versuchen, um zu sehen, ob es noch erscheint; Falls es trotzdem auftritt, prüfen Sie bitte, ob es unter folgende Bedingungen fällt
3. Alle Clients hatten diesen Fehler zufällig und gelegentlich, und wenn dies der Fall ist, handelt es sich oft um ein serverseitiges Problem
Handhabungsmethode: Fehlerbehebung basierend auf der Bereitstellungsarchitektur. Zum Beispiel sind einige Schlüsselprozesse in unserer Bereitstellungsarchitektur nginx----> Gateway-Anwendung----> F5-Lastausgleicher----> Anwendungsserver (docker)
Man kann Schicht für Schicht fehlerbeheben, der einfache Weg ist, direkt eine For-Schleife-Curl-Anfrage mit dem Server-Shell-Befehl zu schreiben und zuerst den Server mit niedrigster Anwendung aufzurufen (wenn man befürchtet, dass der Druck nicht ausreicht, kann man ihn mit mehreren Threads drücken); Drück nacheinander nach oben; Im Stresstest kannst du in Echtzeit sehen, ob die Anfrage hängen bleibt; Wenn es gefunden wird, ist es sehr wahrscheinlich, dass dies das Problem ist:
Derzeit sind wir auf zwei Situationen gestoßen: Auf F5-Ebene werden einige Anfragen erfolglos auf den Anwendungsserver ausgeglichen; Es gibt auch eine Situation, in der es auf Nginx-Ebene feststeckt;
Lösung: Die Lastverteilungsstrategie auf F5-Ebene wurde von Performance L4 auf Standard geändert.
Nginx-Level-Situation Handling Plan: Ich habe an dieser Situation eigentlich nie teilgenommen und verstehe, dass das Ändern vieler nginx-Konfigurationen keinen Effekt hat und schließlich einfach töte und neu installierte, daher habe ich den entscheidenden Punkt nicht gefunden
Meine eigene Lösung: Da der Fiddler 4, den ich benutze, normalerweise nicht geschlossen ist, habe ich Fiddler 4 erneut geöffnet, versucht, die Website anzufordern, und sie kehrte wieder zum Normalen zurück, zu diesem Zeitpunkt schloss ich Fiddler 4 wieder.
|
Veröffentlicht am 22.05.2018 22:57:55
|
|
|
|
