title: Why use Server-Sent Events instead of simple HTTP chunked streaming?
body: <p>I just read <a href="https://www.rfc-editor.org/rfc/rfc6202" rel="nofollow noreferrer" title="RFC-6202">RFC-6202</a> and couldn't figure out benefits of using SSEs instead of simply requesting a chunked stream. As an example use case imagine you want to implement client and server, where the client wants to &quot;subscribe&quot; to events at the server using pure HTTP technology. What would be a drawback of the server keeping the initial HTTP request open and then occasionally sending new chunks as new events come up?
  I found some argument against this kind of streaming, which include the following:</p>
  <ul>
  <li>Since <code>Transer-Encoding</code> is hop-to-hop instead of end-to-end, a proxy in between might try to consolidate the chunks before forwarding the response to the client.</li>
  <li>A TCP connection needs to be kept open between client and server the whole time.</li>
  </ul>
  <p>However, in my understanding, both arguments also apply to SSEs. Another potential argument I could imagine is that a JavaScript browser client might have no chance to actually get the respective chunks, since re-combining them is handled on a lower level, transparent to the client. But I don't know if that's actually the case, since video streams must work in some kind of similar way, or not?</p>
  <p><strong>EDIT:</strong> What I've found in the meantime is that SSE basically is exactly just a chunked stream, encapsulated by a easier-to-use API, is that right?</p>
  <p>And one more thing. <a href="https://hpbn.co/server-sent-events-sse/" rel="nofollow noreferrer" title="This page">This page</a> first tells that SSE doesn't support streaming binary data (for which technical reason?) and then (at the bottom), they say that it is possible but inefficient. Could somebody please clarify that?</p>