New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 275955 link

Starred by 7 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Limit of 6 concurrent EventSource connections is too low

Reported by brent.tu...@gmail.com, Aug 19 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

Example URL:
http://ssebin.btubbs.com/multi/

Steps to reproduce the problem:
1. Visit http://ssebin.btubbs.com/multi/
2. Click Add Counter 6 or more times
3. Try opening another tab to the same address

What is the expected behavior?
You should be able to add more than 6 counters (EventSource connections), and having 6 such connections open should not prevent you from opening the site in another tab.

What went wrong?
After 6 connections, further EventSource connection attempts never complete.  Trying to open the site in another tab results in it spinning indefinitely.

I have an app (https://bitbucket.org/yougov/velociraptor/) that uses two EventSource connections.  I frequently have users who open the app in multiple tabs, and then think that the app has become unresponsive because the browser refuses to connect.  The cap on EventSource connections should be treated more like Websockets than plain http, since they're meant to fill a similar server-push niche.

Did this work before? N/A 

Chrome version: 28.0.1500.95  Channel: stable
OS Version: OS X 10.7.5
Flash Version: Shockwave Flash 11.8 r800

This issue was reported at https://code.google.com/p/chromium/issues/detail?id=80848 but without an easy list of steps to reproduce, and was closed by bugdroid for inactivity.
 
Cc: rponnada@chromium.org
Labels: M-31
Status: Untriaged
Able to repro this issue on MACBookPro with build: 28.0.1500.95 (Official Build 213514) & 29.0.1547.57 

This is non-regression issue, same behavior in M26: & Current beta & Dev:: 30.0.1599.14 & canary:31.0.1608.0 Canary
Labels: -OS-Mac OS-All
Status: WontFix
I don't believe this is a bug. See the spec: http://www.w3.org/TR/2012/WD-eventsource-20120426/#notes:
"""
Clients that support HTTP's per-server connection limitation might run into trouble when opening multiple pages from a site if each page has an EventSource to the same domain. Authors can avoid this using the relatively complex mechanism of using unique domain names per connection, or by allowing the user to enable or disable the EventSource functionality on a per-page basis, or by sharing a single EventSource object using a shared worker. [WEBWORKERS]
"""

It sounds like it's up to the author to work around issues. User agents can impose whatever limits they want. Most modern browsers use a connection per host limit of 6. I understand this is rather lame for web developers, but until we get HTTP/2 and can multiplex these EventSources over a single connection, I don't think there's much we can do here. I recommend you use one of the workarounds suggested in the spec.

Marking as WontFix for now, but feel free to respond if you disagree and we might reopen.
At the corresponding issue on Mozilla's tracker (see https://bugzilla.mozilla.org/show_bug.cgi?id=906896), one suggestion was to make the connection limit per-tab instead of per-browser.  That seems reasonable.  I can limit the number of EventSource connections my app makes, but I can't control how many tabs my users open.

The web worker solution sounds promising.  I'll look into that.

At some level this is a question about the importance of EventSource generally as an alternative to WebSockets.  The connection limit for WebSockets in Mozilla is 200.  I assume Chrome's is similarly large.  With a 6-connection limit in place for EventSource, it's more likely to remain another weird, rarely used HTML5 feature.  That'd be a shame, as EventSource is much easier to program for on the server side (no separate servers on separate ports, no Upgrade headers).
EventSource works nicely as a simple push mechanism. It's much easier to implement on the server compared to websockets, works nicely with most proxies, and has a fairly easy to use fallback option for older browsers (long poll hack via xhr)

http://blog.fastmail.fm/2012/01/09/building-the-new-ajax-mail-ui-part-1-instant-notifications-of-new-emails-via-eventsourceserver-sent-events/

The connection limit issue does suck though. It's annoying that there's a "hack" for websockets to have a larger limit, but none for event source and Chrome and Firefox are both just punting as "won't fix".

Oh well. Being pragmatic, we came up with a hack for inter-tab communication to deal with the connection limit if anyone else runs into this issue.

http://blog.fastmail.fm/2012/11/26/inter-tab-communication-using-local-storage/

 Issue 139688  has been merged into this issue.

Sign in to add a comment