[IE11] Sites that support SPDY do not load first time when IE is configured to use a proxy server and SPDY is enabled - by The Angry Technician

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

ID 813993 Comments
Status Closed Workarounds
Type Bug Repros 15
Opened 1/17/2014 5:00:11 AM
Access Restriction Public


Sites that support the SPDY protocol do not load on the first attempt in Internet Explorer 11 on Windows 8.1 if an HTTP proxy server is configured. When the site is first requested, IE returns a "This page can't be displayed" message, but will display the site correctly if the Refresh button is subsequently pressed, or if the user clicks the address bar and presses Enter to reload the page.

Common sites that use SPDY when it is supported in the browser include www.google.com, mail.google.com, drive.google.com, and other Google properties.

A video of the behaviour can be viewed here: http://www.youtube.com/watch?v=bSwy7dCfn9o

This is 100% reproducible on multiple Windows 8.1 workstations with the above named sites when traffic is passing via a Smoothwall proxy. There are also references online to the same problem when using:

- Websense (http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Windows_8/Q_28272518.html)
- Microsoft TMG (http://windowsexplored.com/2013/10/28/ie-11-page-cant-be-displayed-google-com-spdy3-protocol/)

Current versions of Chrome and Firefox (both with SPDY support) do not exhibit this problem on the same workstation with the same proxy settings, so this appears to be an IE-specific problem rather than a general problem with SPDY via the proxy.
Sign in to post a comment.
Posted by Microsoft on 4/4/2016 at 11:09 AM
We've moved! This issue is now being tracked at https://developer.microsoft.com/microsoft-edge/platform/issues/110924/
Posted by mollymac on 1/4/2015 at 3:08 PM
This is ridiculous spdy.. Facebook problems with no full load of pages. Try to jump over and play games and cannot display page,. Try to read notifications. Page cannot be loaded. New computer sucks
Posted by Naldino74 on 10/31/2014 at 1:32 AM
I'm experiencing more or less the same issue on W10, with some differences:
- sites such http://www.google.com never load, even if I try multiple times;
- if I use HTTPS everythign works correctly;
- on W10 there's non such option to disable SPDY/3 (support has been romeved in this version);
- if I completely disable TLS on IE everything works fine (actually, http-to-https redirection works...)
Posted by uflit on 8/18/2014 at 4:55 PM
I still have this problem just as described above. It occurs on our Windows 8.1 computers, and for all of the users on our Server 2012 R2 RDS farm, Webmarshal is our proxy. I had disabled 'Allow Internet Explorer to use the SPDY/3 network protocol' via group policy, but have an issue now with a site that we have to access that seems to require SPDY to be enabled. Which means I can only access this particular site by checking the SPDY box and bypassing the proxy, which isn't a good solution. Interested to hear if anyone has managed to resolve this.
Posted by NickyMayB on 4/4/2014 at 5:48 AM
Experiencing this with Cisco Ironports. Worked around by disabling SPDY in group policy as suggested.
Posted by EricLaw [ex-MSFT] on 3/21/2014 at 8:28 AM
The KB was pulled. If I had to guess, I'd guess they fixed this in the big "spring" update coming in April.
Posted by RL57 on 3/18/2014 at 5:17 AM
I concur. This is not fixed in the latest update.
Posted by J Schlackman on 3/14/2014 at 7:44 AM
I would also like to confirm that this problem still exists in IE update version 11.0.4 (2925418), despite the claim in KB2928510 (http://support.microsoft.com/kb/2928510) that this problem is fixed in the latest Cumulative Update.
Posted by EricLaw [ex-MSFT] on 3/13/2014 at 12:18 PM
I've attached an updated cap (SPDY-via-RemoteProxyFailure.cap) which shows the traffic from IE to the proxy (rather than from the proxy to the server). It shows that IE is abruptly RST'ing the connection after acknowledging data from the server (the FIN in the earlier capture was from the proxy to the server, after the client had RST'd the connection to the proxy).

IE version 11.0.4 on Win8.1.
Posted by EricLaw [ex-MSFT] on 3/13/2014 at 11:15 AM
I can reproduce this about 5% of the time when I have Fiddler running with the "Capture HTTPS Connects" enabled and "Decrypt HTTPS traffic" disabled (such that the SPDY tunnel flows through Fiddler without any decryption.) I've attached a NetMon capture of the failure; IE FINs the connection rather abruptly shortly after the handshake completes and RSTs the connection after the server replies with an encrypted alert.

Perhaps a race condition where a "This socket is encrypted" flag is getting properly set but the "This socket is SPDY" flag isn't properly set in time to prevent incorrect reuse?
Posted by hafka on 3/3/2014 at 1:14 AM
I have the same problem, disabling SPDY in IE11 settings helps.
Posted by Microsoft on 2/25/2014 at 10:27 AM
Thank you for your feedback. We will be investigating this issue further.

Best regards,

The Internet Explorer Team
Posted by euangriff on 2/25/2014 at 8:39 AM
Experiencing this behind a WebMarshal Proxy.
Posted by Richard Archer on 2/11/2014 at 1:57 AM
I can confirm we are experiencing this bug behind a BlueCoat proxy
Posted by LeeCarlCooper on 2/7/2014 at 2:27 AM
We have experienced this issue using a Sophos Web Proxy.
Posted by PaulMilbank on 1/31/2014 at 5:13 PM
We are experiencing this bug behind an ISA 2006 firewall/proxy server.
On researching, Firefox had the same issue with their implementation of SPDY. This has been fixed as of this thread:
I believe this is the patch that fixed it for them taken from a link in the same bugzilla thread.
I can confirm that Chrome and Firefox on our deployed base of Windows 8.1 machines do not exhibit the same issue.
Posted by DJL on 1/21/2014 at 2:12 PM
We have experienced the same issue behind TMG as well as Squid 3.0.10