net::ERR_HTTP2_PROTOCOL_ERROR 是什么? [英] What's the net::ERR_HTTP2_PROTOCOL_ERROR about?

问题描述

我目前正在处理一个网站，该网站在 Google Chrome 上触发了 net::ERR_HTTP2_PROTOCOL_ERROR 200 错误.我不确定究竟是什么会引发此错误，我只是注意到它仅在以 HTTPS 访问网站时才会弹出.我不能 100% 确定它是相关的，但看起来它会阻止 JavaScript 正确执行.

例如，发生以下情况:

1. 我使用 HTTPS 访问网站

2. 我通过

   Google Chrome 标头(有错误):

   Firefox 标题(没有错误):

   控制台中的 curl --head --http2 请求返回以下成功:

   HTTP/2 200日期:2019 年 10 月 4 日星期五 08:04:51 GMT内容类型:文本/html；字符集=UTF-8内容长度:127089设置cookie:SERVERID31396=2341116；路径=/；最大年龄=900服务器:阿帕奇x-power-by: PHP/7.2设置 cookie:xxxxx=0919c5563fc87d601ab99e2f85d4217d；到期=周五，2019 年 10 月 4 日 12:04:51 GMT；最大年龄=14400；路径=/；安全的;仅Http变化:接受编码

   ---

   尝试更深入地使用 chrome://net-export/和 https://netlog-viewer.appspot.com 工具告诉我请求以 RST_STREAM 结束:

   t=123354 [st=5170] HTTP2_SESSION_RECV_RST_STREAM-->error_code = "2 (INTERNAL_ERROR)";-->流 ID = 1

   对于我在另一篇文章中读到的内容，在HTTP/2，如果客户端想中止请求，它会发送一个 RST_STREAM.当服务器收到 RST_STREAM 时，它将停止向客户端发送 DATA 帧，从而停止响应(或下载).该连接仍可用于其他请求，并且与已中止的请求/响应并发的请求/响应可能会继续进行.[...]有可能在 RST_STREAM 从客户端传输到服务器时，请求的全部内容都在传输中并将到达客户端，客户端将丢弃它.但是，对于较大的响应内容，发送 RST_STREAM 可能有很好的机会在整个响应内容发送之前到达服务器，因此会节省带宽."

   所描述的行为与我观察到的行为相同.但这意味着浏览器是罪魁祸首，然后我不明白为什么它会发生在两个相同的页面上，一个有 200 个标题，另一个有 404(如果我禁用 JS，情况也是如此).

   解决方案

   我不知道到底发生了什么，但我找到了解决方案.

   OVH 的 CDN 功能 是罪魁祸首.我已将它安装在我的主机服务上，但由于我不需要它而对我的域禁用.

   不知何故，当我启用它时，一切正常.

   我认为它强制 Apache 使用 HTTP2 协议，但我不明白的是，我的每个标头中确实提到了 HTTP2，我认为这意味着服务器正在使用正确的协议进行响应.

   因此，针对我的非常特殊情况的解决方案是在所有相关域上启用 CDN 选项.

   如果有人更了解这里可能发生的事情，请随时分享解释.

   I'm currently working on a website, which triggers a net::ERR_HTTP2_PROTOCOL_ERROR 200 error on Google Chrome. I'm not sure exactly what can provoke this error, I just noticed it pops out only when accessing the website in HTTPS. I can't be 100% sure it is related, but it looks like it prevents JavaScript to be executed properly.

   For instance, the following scenario happens :

   1. I'm accessing the website in HTTPS

   2. My Twitter feed integrated via https://publish.twitter.com isn't loaded at all

   3. I can notice in the console the ERR_HTTP2_PROTOCOL_ERROR

   4. If I remove the code to load the Twitter feed, the error remains

   5. If I access the website in HTTP, the Twitter feed appears and the error disappears

   Google Chrome is the only web browser triggering the error: it works well on both Edge and Firefox. (NB: I tried with Safari, and I have a similar kcferrordomaincfnetwork 303 error)

   I was wondering if it could be related to the header returned by the server since there is this '200' mention in the error, and a 404 / 500 page isn't triggering anything.

   Thing is the error isn't documented at all. Google search gives me very few results. Moreover, I noticed it appears on very recent Google Chrome releases; the error doesn't pop on v.64.X, but it does on v.75+ (regardless of the OS; I'm working on Mac tho).

   ---

   Might be related to Website OK on Firefox but not on Safari (kCFErrorDomainCFNetwork error 303) neither Chrome (net::ERR_SPDY_PROTOCOL_ERROR)

   ---

   Findings from further investigations are the following:

   • error doesn't pop on the exact same page if server returns 404 instead of 2XX
   • error doesn't pop on local with a HTTPS certificate
   • error pops on a different server (both are OVH's), which uses a different certificate
   • error pops no matter what PHP version is used, from 5.6 to 7.3 (framework used : Cakephp 2.10)

   As requested, below is the returned header for the failing ressource, which is the whole web page. Even if the error is triggering on each page having a HTTP header 200, those pages are always loading on client's browser, but sometimes an element is missing (in my exemple, the external Twitter feed). Every other asset on the Network tab has a success return, except the whole document itself.

   Google Chrome header (with error):

   Firefox header (without error):

   A curl --head --http2 request in console returns the following success:

   HTTP/2 200 
   date: Fri, 04 Oct 2019 08:04:51 GMT
   content-type: text/html; charset=UTF-8
   content-length: 127089
   set-cookie: SERVERID31396=2341116; path=/; max-age=900
   server: Apache
   x-powered-by: PHP/7.2
   set-cookie: xxxxx=0919c5563fc87d601ab99e2f85d4217d; expires=Fri, 04-Oct-2019 12:04:51 GMT; Max-Age=14400; path=/; secure; HttpOnly
   vary: Accept-Encoding
   

   ---

   Trying to go deeper with the chrome://net-export/ and https://netlog-viewer.appspot.com tools is telling me the request ends with a RST_STREAM :

   t=123354 [st=5170]    HTTP2_SESSION_RECV_RST_STREAM
                         --> error_code = "2 (INTERNAL_ERROR)"
                         --> stream_id = 1
   

   For what I read in this other post, "In HTTP/2, if the client wants to abort the request, it sends a RST_STREAM. When the server receives a RST_STREAM, it will stop sending DATA frames to the client, thereby stopping the response (or the download). The connection is still usable for other requests, and requests/responses that were concurrent with the one that has been aborted may continue to progress. [...] It is possible that by the time the RST_STREAM travels from the client to the server, the whole content of the request is in transit and will arrive to the client, which will discard it. However, for large response contents, sending a RST_STREAM may have a good chance to arrive to the server before the whole response content is sent, and therefore will save bandwidth."

   The described behavior is the same as the one I can observe. But that would mean the browser is the culprit, and then I wouldn't understand why it happens on two identical pages with one having a 200 header and the other a 404 (same goes if I disable JS).

   解决方案

   I didn't figure out what exactly was happening, but I found a solution.

   The CDN feature of OVH was the culprit. I had it installed on my host service but disabled for my domain because I didn't need it.

   Somehow, when I enable it, everything works.

   I think it forces Apache to use the HTTP2 protocol, but what I don't understand is that there indeed was an HTTP2 mention in each of my headers, which I presume means the server was answering using the right protocol.

   So the solution for my very particular case was to enable the CDN option on all concerned domains.

   If anyone understands better what could have happened here, feel free to share explanations.

   这篇关于net::ERR_HTTP2_PROTOCOL_ERROR 是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！