当使用一些包(如webpack-hot-middleware)并同时打开多个页面时，也会出现此问题。Webpack-hot-middleware将为每个页面创建一个连接，用于侦听代码的更改，然后刷新页面。每个浏览器都有每个服务器最大连接数限制，对于Chrome来说是6个，所以如果你已经在Chrome中打开了超过6个页面，新的请求将一直挂在那里，直到你关闭一些页面。

我怀疑我的回答是否能及时帮助到你，但其他人可能会觉得它有帮助。我在创建jQuery Ajax Post脚本时遇到了类似的问题。

原来，我有一个错字在一个标签的href属性，我正在使用火的帖子。我输入了href=" javacscript:;"(颠倒's'和'c')..这导致脚本在文章试图触发时尝试刷新页面。纠正了拼写错误，它为我工作得很好。

在我的情况下，我在post请求中发送的主体参数，以及我根据主体参数编写的逻辑都是错误的，因此无法发送响应。所以我得到了这个错误。

 example: post request body (a: alsldfjfj) which I was sending

但我写的代码是验证“b”而不是“a”

我遇到过这个，当我从https切换到http时，它就消失了。我们在开发中使用的SSL证书没有经过第三方的验证。它们只是本地生成的开发证书。

同样的调用在Chrome Canary和Firefox中也能正常运行。这些浏览器似乎不像Chrome那样严格要求SSL证书。调用将失败在Chrome与“警告:临时头…”消息。

我认为/希望当我们在阶段和prod中使用合法的SSL证书时，我们将不再在Chrome中看到这种行为。

My situation is cross-origin related. Situation: Browser sends OPTIONS request before sending the real request like GET or POST. Backend developer forgets to deal with the OPTIONS request, letting it go through the service code, making the processing time too long. Longer than the timeout setting I wrote in the axios initialization, which is 5000 milliseconds. Therefore, the real request couldn't be sent, and then I encountered the provisional headers are shown problem. Solution: When it comes to OPTIONS request, backend api just return result, it makes the request faster and the real request can be sent before timeout.

HTTP/2推送资源将产生临时头显示在检查器中，与@wvega在上面的回答中发布的理论相同。

例:由于服务器将资源推送到客户端(在客户端请求它们之前)，浏览器已经缓存了这些资源，因此客户端从不发出/需要请求;所以因为…

.．.当服务器响应时更新真实的头，但是如果请求被阻塞，则没有响应。