[88913527]

HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers.

Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream):

https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s...

[0]: https://en.wikipedia.org/wiki/Chunked_transfer_encoding

[patrickthebold]

Maybe I misunderstood your claim, but there is: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr...

Which seems to be what you need to send 'headers' after a chunked response.

[88913527]

You understood correctly; I was mis-informed. Today I learned about the "Trailer" header. I'm curious how HTTP clients handle that. A client like window.fetch will resolve with a headers object-- does it include the trailers or not? I'd have to test it out.

[tehbeard]

More so the issue is the "native" browser client, EventSource [1] is pretty much just url and "withCredentials" (send/don't send cookies)

You can kludge it with fetch(...) and the body stream

1. <https://developer.mozilla.org/en-US/docs/Web/API/EventSource>

[yencabulator]

SSE comes from a time when browser APIs toward Javascript forced a full download of the response body before it was handed to the Javascript.

With current day APIs, including streaming response bodies in the fetch API, SSE would probably not have been standardized as a separate browser API.