This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the non normative document introduction "Editor's Draft 26 August 2012" http://dev.w3.org/html5/eventsource/ it is mentionned: >Clients will reconnect if the connection is closed; a client can be told to stop reconnecting using the HTTP 204 No Content response code. This is the only moment in the document where this scenario is being given as a possibility for "blocking the reconnection". A scenario could be 1. Event Stream being opened by the client 2. The server could drop the connection 3. The client tries to reconnect 4. The server replied 204 5. The client definitely drops the connection There is a discussion on HTTP code in 5. Processing Model but which basically says that >Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection. So it seems to include 204, but that doesn't make it clear either. I haven't checked if it was even implemented interoperably in between browsers. Suggestion: Either of those: * Specify it in the section 5 with other HTTP codes * Remove the sentence "a client can be told to stop reconnecting using the HTTP 204 No Content response code."
Karl - today Hixie closed related bug 15495 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15495). Does that fix (http://html5.org/tools/web-apps-tracker?from=7449&to=7450) address the issue you raise in this bug (18796)? FWIW, I agree it seems a bit strange to have what appears to be normative text about code 204 in the non-normative Section 1 and that text does appear to contradict what is said in Section 5 re all other codes not listed here must cause the UA to fail the connection. Hixie - should the information about code 204 in Section 1 be removed (as Karl suggests)?
Failing the connection is exactly what 204 does, which is what the intro section says it does... I don't understand the problem here.
The "204" answer is implicited included in this section 5 sentence: "Any other HTTP response code not listed here must cause the user agent to fail the connection." Though 204 has no specific meaning in the context of server sent events because in fact any kind of 2** code will terminate the connection but "200 with the right mime-type". Maybe I would expect in the intro more something along "A client could be told to stop reconnecting using the HTTP 204 No Content response code (but not exclusively)." Hixie, Art, I can live with it. Thanks for considering the bug.