BrowserChannel: Use XHR Streaming (instead of forever iframes) on IE8+

[GoogleCodeExporter]

In IE, BrowserChannel uses "Forever IFrames" to implement the back channel 
connection. All other browsers use XHR Streaming for the back channel 
connection. Recent versions of IE (IE8+) support XHR Streaming [1] making 
Forever IFrames only necessary on IE7 and below.

This change makes IE8+ use XHR Streaming instead of Forever IFrames and thus 
function like other browsers.

http://codereview.appspot.com/4684046

Please see this cld thread for more discussion:

http://groups.google.com/group/closure-library-discuss/browse_thread/thread/20b0
e16dd0049a08

[1]

http://my.safaribooksonline.com/book/web/9780596803773/s/115

"""
Several browsers provide support for streaming through XHR, including Firefox, 
Safari, Chrome, and Internet Explorer 8. Like the forever-frame technique, XHR 
streaming allows successive messages to be sent from the server without 
requiring a new HTTP request after each response.

While the lack of support for streaming in Internet Explorer versions 7 and 
earlier precludes complete reliance on a streaming-based protocol, we can 
certainly leverage streaming when it is available to improve performance. When 
available, XHR streaming is currently the best-performing Comet transport in 
the browser since it does not require the overhead of an iframe or script tags 
(as the forever-frame technique does), and can continuously utilize a single 
HTTP response (which long polling doesn’t do).
"""

Original issue reported on code.google.com by ahochhau...@gtempaccount.com on 11 Jul 2011 at 4:37

[GoogleCodeExporter]

Fixed by http://code.google.com/p/closure-library/source/detail?r=1158.

Original comment by mdav...@gmail.com on 27 Jul 2011 at 7:12

[GoogleCodeExporter]

Original comment by mdav...@gmail.com on 27 Jul 2011 at 7:12

• Changed state: Fixed

[GoogleCodeExporter]

This change had to be rolled back. We've verified that it broke things on IE8 
and IE9 in the real world. :( I was excited about this change too.

Michael is currently on vacation, but he's agreed that he will figure out what 
happened when he gets back. Thanks Michael!

Original comment by Nicholas.J.Santos on 3 Aug 2011 at 9:22

• Changed state: New

[GoogleCodeExporter]

Thanks Nick.

Do you have any more details about what broke? I might be able to look into it 
before Michael comes back.

Original comment by ahochhau...@gtempaccount.com on 3 Aug 2011 at 9:25

[GoogleCodeExporter]

Your two changes were combined into one, so it could've been this or the other 
one. 

It made IE8 & IE9 on Gmail not get streaming responses.

Original comment by mdav...@gmail.com on 3 Aug 2011 at 9:31

[GoogleCodeExporter]

I've been playing around with this more recently, and as far as I can tell, 
this doesn't work.

According to
http://blogs.msdn.com/b/ieinternals/archive/2010/04/06/comet-streaming-in-intern
et-explorer-with-xmlhttprequest-and-xdomainrequest.aspx
the IE team never implemented it.

Original comment by Nicholas.J.Santos on 15 Nov 2011 at 6:18

[GoogleCodeExporter]

Thanks Nick. You are definitely right.

The errata for "Even Faster Web Sites" has the following correction:

http://oreilly.com/catalog/errata.csp?isbn=9780596522315

"""
Page 115 2nd paragraph: IE8 does not support XHR streaming, so it should be 
removed from the list of browsers.
"""

I also tested your recent change 
(http://code.google.com/p/closure-library/source/detail?r=1388) against my 
browserchannel server to confirm XHR streaming on IE8/9 does _not_ work. Per 
your link, it looks like XDomainRequest could be a possible alternative.

This bug can be closed, sorry for the confusion.

Original comment by ahochh...@samegoal.com on 15 Nov 2011 at 11:08

[GoogleCodeExporter]

oh, errata. :)

Original comment by nicksan...@google.com on 15 Nov 2011 at 11:29

• Changed state: Invalid