Unexpected closing of HTTP2 connection with description ABANDONED
Reported by
fredrik....@gmail.com,
Jun 1 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Open https://www.omnizens.com/service/api/recommendation/view/list/1-12779/#details in the browser. 2. Check for more than one broken image in the images being displayed. 3. If images are loaded correctly, reload the page (with the browser cache disabled) until the problem appears. What is the expected behavior? Only one broken image should be shown (we've kept this here as it seems that pages that have a broken image makes it easier to reproduce the error) What went wrong? We intermittently get broken images even for the ones that shouldn't have any problems when loading. In the net-internals file attached, we can see that for the unexpectedly broken images it gives a HTTP2_STREAM_ERROR with description text ABANDONED. After this a new HTTP2_SESSION is created so it seems as if someone is closing the connection. Did this work before? N/A Chrome version: 58.0.3029.110 Channel: stable OS Version: 10.0 Flash Version: At this moment we don't know if this is a problem on the client side or on the server side and need to find out the reason for the HTTP2_STREAM_ERROR. I found another issue (https://bugs.chromium.org/p/chromium/issues/detail?id=657755) where it is hinted that abandoned is made on the server side but in this issue they get a ERR_CONNECTION_CLOSED and we get ERR_SPDY_PROTOCOL_ERROR so it doesn't seem to be the same problem. We have tried but not been able to reproduce the error using Firefox and Edge, but have been able to reproduce it from a few machines using Chrome.
,
Jun 2 2017
Looks like this was caused by an invalid control frame:
t=16820 [st=12607] HTTP2_SESSION_CLOSE
--> description = "Framer error: 2 (INVALID_CONTROL_FRAME)."
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
It's possible other browsers are ignoring the frame, or we could incorrectly be thinking it's invalid. I'll defer to the H2 folks, but we may need to get at just what that control frame looks like to know where to go from here.
,
Jun 13 2017
,
Jun 13 2017
Sorry for the slow response. I cannot reproduce the issue. Protocol error might be a bug in the server, or it might be a bug in Chrome. If you can reproduce the error, you could help me by recording network events in more detail: that would allow me to see exactly what bytes are exchanged between Chrome and the server, and I could determine which peer has the bug. In order to do that, please open an incognito window, then close every other Chrome window, including ones open with a different user profile. Navigate to chrome://net-export in your incognito window, select "Include raw bytes (will include cookies and credentials)", then press "Start logging to disk". While keeping this tab open, start a new tab, navigate to https://www.omnizens.com/service/api/recommendation/view/list/1-12779/#details or whatever other link gets you to reproduce the error. Once you encounter this error, save the log as usual. Note that this log contains every byte sent and received. If the browser does not send any passwords or authentication cookies, then this should not be a privacy issue, but it is wiser if you do not post this publicly anyway. Please e-mail me the log at bnc@chromium.org. Thank you.
,
Jun 15 2017
Thank you for the network log with raw bytes. I see an error happening, though it is a bit different from the error in the network log attached to the opening post. This time, it is:
t=2773 [st=822] HTTP2_SESSION_CLOSE
--> description = "Framer error: 16 (OVERSIZED_PAYLOAD)."
--> net_error = -362 (ERR_SPDY_FRAME_SIZE_ERROR)
Unfortunately, the corresponding socket was opened before logging started, so the raw data are not recorded. In any case, this is also a kind of protocol error. However, the server seems to be Apache, which is fairly common, so if there really was an incompatibility between that and Chrome, it would have probably been already found.
I keep wondering if your antivirus or firewall is intercepting encoded HTTP/2 traffic, and maybe has a bug in its HTTP/2 framing layer. Would you mind trying with antivirus and firewall disabled, so see if you can reproduce the error? Thank you.
For what it's worth, I cannot reproduce it on either Chrome 59.0.3071.86 or 60.0.3112.10.
,
Jun 22 2017
@fredrik: Any luck with trying the experiment requested in c#5?
,
Jun 29 2017
Hi, sorry for the late response. I sent a file to bnc@google.com since this was the address used by the latest communication I had concerning this issue. I have now attached this file again in response to this message and I hope that you are able to receive it (it's about 50MB so you should receive it as a Google Drive link). Below is also the original content of my email response. Regards, Fredrik Andersson Chrome - Raw bytes - full.zip <https://drive.google.com/file/d/0B7ie7kpC3m15NlpWcUo0S2IxaW8/view?usp=drive_web> Hi, I have attached a new file which hopefully has everything from the start of the session. My Chrome is having problem when I try to search the events using chrome://net-internals so I haven’t been able to verify which of the detailed errors was received for this file. It is correct that we have Apache servers for the application. However, the HTTP2 communication is terminated at the CDN network we’re using. Internally from the CDN network to the servers, HTTP1.1 is used. I have been able to reproduce the error also with the antivirus turned off. However, for the file I attached the antivirus is still on, since this file was a lot smaller than the other files I got while reproducing the error (since the error is not occurring for each request, it can take some reloads until the error occurs). 2017-06-22 20:52 GMT+02:00 rdsm… via monorail < monorail+v2.2679445682@chromium.org>:
,
Jun 29 2017
Thank you for providing more feedback. Adding requester "bnc@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 29 2017
Thank you for providing the log. Unfortunately Chrome crashes for me when I'm trying to open it. I'll see if I can use some other tool to analyze the log, but it might take some time.
,
Aug 30 2017
From the log provided, I see two protocol errors. In 50220 HTTP2_SESSION:
t=36511 [st=33623] HTTP2_SESSION_CLOSE
--> description = "Framer error: 11 (INVALID_DATA_FRAME_FLAGS)."
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
Then in 53008 HTTP2_SESSION:
t=37067 [st=493] HTTP2_SESSION_CLOSE
--> description = "Framer error: 2 (INVALID_CONTROL_FRAME)."
--> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)
,
Nov 11
Hi; I have encountered the same prolem when access to this video (https://testforcbg-xn.obs.cn-southwest-2.myhwclouds.com/%E5%8A%A0%E5%85%A5%E5%8D%8E%E4%B8%BA%EF%BC%8C%E5%A4%A7%E6%9C%89%E5%8F%AF%E4%B8%BA%EF%BC%8CJust_Waiting_For_U%EF%BC%81.mp4 ) by using chrome 8.0.3440.106 (cohort: Stable) and any other chrome support h2 . sometimes this video could not be loaded because of the following error. while I refresh this video it could be reloaded and played normally; it never happened using firefox. no log of the second request is found in server jetty.log. I am asking for help here. thanks a lot. more information will attached later. Then in 53008 HTTP2_SESSION: t=37067 [st=493] HTTP2_SESSION_CLOSE --> description = "Framer error: 2 (INVALID_CONTROL_FRAME)." --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) wireshark information cloud be filtered by condigtion : ip.dst == 139.9.224.10 || ip.src == 139.9.224.10 @chromium.org My E-mail address:axuefeng1990@gmail.com |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mattm@chromium.org
, Jun 1 2017