When running in SSL, opening window with Web Sockets causes buffer lock
Reported by
bennslo...@gmail.com,
Mar 17 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36 Steps to reproduce the problem: 1. From one webpage, programmatically(Using the window object) open a new tab and load a page with websockets over an SSL Connection(Same server). 2. New tab never loads 3. Chrome asks you whether you want to kill the page What is the expected behavior? Tab opens and the page loads What went wrong? From what I can tell, the problem is that Chromes read buffer is full and it continues to throw a zero window response to our server. Our server is correctly sending down a Zero Window Probe request for this, and continues to do so when it's trying to write new data to the client. This just continues indefinitely until the newly opened window is closed. Our server isn't receiving anything from Chrome at this point either, as to rule out a dead lock between the server and client filling buffers. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 57.0.2987.98 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 25.0 r0
,
Mar 21 2017
,
Apr 5 2017
,
Apr 6 2017
Could you provide a net-internals log? https://dev.chromium.org/for-testers/providing-network-details Also, it would be great if you could provide a reproducible html, scripts, jsfiddle url, etc.
,
May 8 2017
No feedback was received in the last 30 days from reporter "bennslough@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by nyerramilli@chromium.org
, Mar 20 2017