Chrome request says "Provisional headers are shown":
The first time the browser sends this request, the request is blocked and no response is received. When the browser is asked to send this request again, the browser will report this warning if the previous same request has not been responded to, so where will the problem be?
I encountered it several times in the project, and I will introduce different scenarios respectively:
1. Provisional headers are showing when accessing the browser of all clients:
How to deal with it: Check the page where the request was triggered to see if the form submission and ajax request are triggered at the same time.
For example, define a button, type is submit, and define an ajax event for the button;
This scenario is one of those that has arisen in our previous development process
2. Some client browsers appear
How to deal with it: Call chrome's chrome://net-internals/#events, then retrigger the request, and then check the log of requests where Provisional headers are shown;
See if delegate_blocked_by keywords exist; This is generally due to the browser plug-in or the client's software intercepting the request; The situation we have is intercepted by WebSense Endpoint;
If this is the case, it can basically be ignored, the client's own problem; You can consider uninstalling the plugin or software and try again to see if it still appears; If it still occurs, please see if it falls under the following conditions
3. All clients have had this error randomly and occasionally, and if this is the case, it is often a server-side problem
Handling method: Troubleshoot based on the deployment architecture. For example, a few key processes in our deployment architecture are nginx----> gateway application----> F5 load balancer----> application server (docker)
You can troubleshoot layer by layer, the simple way is to directly write a for loop curl request with the server shell command, and first call the lowest application server (if you are afraid that the pressure is not enough, you can depress it with multiple threads); Press up in turn; In the process of stress testing, you can see in real time whether the request will be stuck; If found, it is very likely that this is the problem:
At present, we have encountered two situations, one is at the F5 level, some requests are unsuccessfully load balanced to the application server; There is also a situation where it is stuck at the nginx level;
Solution: The load balancing strategy at the F5 level has been changed from performance L4 to standard.
nginx level stuck situation handling plan: I have not actually participated in this situation, and I understand that modifying many configurations of nginx has no effect, and finally just kill and reinstall, so I didn't find the key point
My own solution, because the Fiddler 4 I use is not closed normally, so I reopened Fiddler 4, tried to request the website and it returned to normal, at this time, close Fiddler 4 again.
|
Posted on 5/22/2018 10:57:55 PM
|
|
|
|
