Ajax,axios request, webpack proxy, the 5-minute timeout set by the frontend, why does the browser display the timeout in 2 minutes?
my problem has been solved. It is the timeout of webpack"s proxy default setting. Just modify the default timeout.
the following key points:
timeout: 1920000,
detailed configuration:
proxyTable: {
timeout: 1920000,
}
},
found this similar problem on stackoverflow after searching for a long time.
https://stackoverflow.com/que...
I felt that this might be the reason, and then I created a new project on this machine that did not use proxy and found that there was no 2-minute limit, so it was very likely that the webpack agent set the timeout. I looked around the webpack official website and did not find the corresponding api
https://webpack.js.org/config...
.
I set a timeout of 5 minutes at the front end,
No timeout is set for the backend springboot;
however, two minutes after the request is made, the browser prompts for a timeout;
where are these two minutes set? Where is the default configuration of the browser or the back end
disagree with upstairs, 2 minutes timeout is not determined by the browser. http1.1 only specifies that the browser retry after socket is broken.
2 minutes is a default convention, such as http_server_timeout of nodejs , which defaults to 2 minutes if you don't set it.
so you should continue to check for server-side timeouts. If the situation on the server side is complex, you need to check for timeout areas one by one.
XMLHttpRequest/timeout
that "two minutes" is determined by the browser, and for most browsers, the timeout cannot be changed.
instead of changing the timeout, find out why it timed out.
recently encountered the same question, found the answer, to answer a wave. In fact, all browsers have a default time, but the settings are different, and our longest chrome timeout is 5 minutes , while two minutes is the timeout time set by node's default http request. see here
suggest that you refer to the upstairs method and go in two steps: upload first, process later, and don't affect what you like during processing. You can even import multiple 50m files at one time and let the server deal with them slowly.
1. take a look at the configuration of nginx , whether there is a limit on the timeout
2. Large files are uploaded with multipart upload handles, and it is also possible to verify the validity of sharding. Yours is not safe either. If the 50m upload interface is caught by others, it will not bring down your server
.
I came across a similar one before, which was also asked on codeshelper. I would like to give you a more reasonable answer for your reference: (the following answer is excerpted from https://codeshelper.com/q/10...)
.
1. There must be timeouts, and there are multi-level settings
such as layer 7 HTTP timeout, and settings such as Nginx and Apache
there are also layer 4 TCP timeout
intermediate network nodes, and there is also the possibility of timeout
2. It is not recommended to set overly long requests
3. According to the time-consuming reasons, change the policy
if the slow speed caused by the operation type of the interface, is it possible to cache the interface data in advance and generate the interface data in advance
if the download type requires real-time generation of download files, it can be changed to multiple requests.
the first request first applies for the download task
the second request starts training whether the download task is ready
the third request is to download files directly
Supplementary content
upload of super-large files can also be handled at the front end. Use FileAPI to split and upload files
https://www.html5rocks.com/zh...
PS: uploading files and comparing data can also be split into two APIs.
upload the API just upload, how fast, how to experience good, how to come.
get the data after comparison, which is a kind of operation type interface, and can also be released separately.
