Issue metadata
Sign in to add a comment
|
Transport socket pool per host exausted with PDF download
Reported by
ricardo....@gmail.com,
Dec 7
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Example URL:
N/A
Steps to reproduce the problem:
This was observed on Chrome 70.0.3538.110 on both Windows 10 and CentOS.
1. Start chrome.
2. Enable download PDF instead of showing it (chrome://settings/content/pdfDocuments);
3. Access any page with an iframe source pointing to a PDF file (any pdf file will do), such as:
<html>
<head>
</head>
<body>
Test
<iframe id="myframe" name="myframe" style="width: 100%; height: 883px;" frameborder="0" src="sample.pdf"></iframe>
</body>
</html>
4. Force refresh 6 times or so;
5. Try to make any other request to the same host;
6. Check chrome://net-internals/#sockets
What is the expected behavior?
Further requests to host should have completed normally, instead of being queued.
What went wrong?
Transport socket pool gets full for that particular host, even if no actual download takes place. Sockets remain listed as active on net-internals even after closing the tabs.
Did this work before? N/A
Chrome version: 70.0.3538.110 Channel: n/a
OS Version: 10.0
Flash Version:
Embedded and object PDFs on root document, or direct links won't trigger the issue, nor will this sample code if the aforementioned option is disabled.
This seems to be happen irrespective of the HTTP server. I've tested this hosting the PDF and HTML file Nginx 1.15.7, then on Tomcat 7.0.85, issue occurred both times.
,
Dec 10
Hi there, this does seem like an issue. Could you please provide a specific site where we can try reproducing this?
,
Dec 10
,
Dec 10
I've first discovered this issue with custom reports on our corporate website, so that is unfortunately not available for the general public. However, after some digging I found a website "in the wild" that did to trigger the issue: http://teamregina.ca/calendar Just try not to DOS the poor dude! I'd attach evidence but my Chrome got updated and chrome://net-internals/#sockets doesn't show anything anymore.
,
Dec 10
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 14
Can you try with Google Chrome Canary and see if the problem is fixed there? This is likely bug 872284 . Also, this is not a FTP bug.
,
Dec 14
Good catch, thestig. Issue was not reproducible on Chrome Canary, so this should be closed as it is definitely a duplicate of bug 872284 (and not FTP-related at all). Thanks everyone.
,
Dec 14
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 14
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Dec 9