Issue metadata
Sign in to add a comment
|
Webpage with large amount of images (2900+) causes some of the image downloads to be canceled.
Reported by
koconnor...@gmail.com,
Feb 6 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Example URL: Steps to reproduce the problem: 1. Open the dev tools network tab. 2. Open a webpage with 2900+ images. 3. Observe that some of the image requests are canceled. What is the expected behavior? All images should download. What went wrong? Some of the image downloads are canceled. Did this work before? N/A Chrome version: 64.0.3282.140 (Official Build) (64-bit) (cohort: 64_140_win) Channel: stable OS Version: 10.0 Flash Version: I don't experience this problem in Firefox, Edge, or IE.
,
Feb 6 2018
I can't provide a NetLog for the page I'm working with due to work restrictions. I'm going to try to reproduce the problem with a dummy page and attach a NetLog.
,
Feb 6 2018
Thank you for providing more feedback. Adding requester "davidben@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
,
Feb 6 2018
,
Feb 7 2018
,
Feb 7 2018
I wasn't able to reproduce the problem in a simpler setting, but I did realize we recently upgraded our proxy server to use HTTP/2. After disabling HTTP/2 all the images load correctly.
,
Feb 7 2018
Thank you for providing more feedback. Adding requester "davidben@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
,
Feb 7 2018
Could you try reproducing it in an HTTP/2 setting and get a NetLog? We throttle requests less over HTTP/2, so it's possible this is then hitting issue #798977 , while the HTTP/1.1 behavior doesn't hit it? +mmenke
,
Feb 7 2018
Sure, I actually didn't try HTTP/2 when trying to reproduce the bug. I'll try it and see what happens.
,
Feb 7 2018
Thank you for providing more feedback. Adding requester "davidben@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
,
Feb 7 2018
I was able to reproduce the problem and I see a lot of ERR_CONNECTION_RESET errors in the console log which I didn't see where I originally encountered the problem. The NetLog is too big so I'm zipping it.
,
Feb 8 2018
,
Feb 14 2018
Thank you for the NetLog. Seems like server sends a GOAWAY frame:
t=5575 [st=2615] HTTP2_SESSION_RECV_GOAWAY
--> active_streams = 128
--> debug_data = "[0 bytes were stripped]"
--> error_code = "0 (NO_ERROR)"
--> last_accepted_stream_id = 1999
--> unclaimed_streams = 0
Some time after this the connection is closed before data for a number of streams with stream ID smaller than or equal to 1999 could arrive, which is an error.
This is not an issue with Chrome. It is suspected that the server actually writes the missing data frames to the socket, but then closes the socket in such a way that the kernel discards them. See related issue 796199 .
,
Feb 14 2018
Thanks, we are using NGINX so that makes sense. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by davidben@chromium.org
, Feb 6 2018