This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.w3.org/TR/eventsource/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: I need some way of recovering from longer but still temporary failures, without requiring a complete page refresh, and without requiring every all events of interest to be rebound, or otherwise handled differently from any other event. This isn't an issue with the WebSocket and XMLHttpRequest API's, as those interfaces already require one to implement an event passing scheme on top, making it trivial to replace the underlying WebSocket or XMLHttpRequest. While such a scheme could also be implemented on top of EventSource, it seems silly to stack an different event source scheme on top of something called "EventSource". Posted from: 70.64.129.37 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/10.04 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2
The design assumes that when there is a network problem, the script will create a new object. This doesn't seem particularly burdensome...
People have suggested we change the model here, so I'll have a look to see how to do that.
*** Bug 18320 has been marked as a duplicate of this bug. ***
Checked in as WHATWG revision r7450. Check-in comment: Change EventSource so that it retries the connection in case of certain 5xx errors and in case of DNS errors or failed connections at the TCP level http://html5.org/tools/web-apps-tracker?from=7449&to=7450