-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server-Sent Events (SSE) - add Keep-Alive Messages definition #7571
Comments
Why do you need to know that a comment is specifically being used to keep the connection alive? Also you broke the text encoding in your pull request. spec link: https://html.spec.whatwg.org/multipage/server-sent-events.html#authoring-notes |
@Yay295 |
So if this keep-alive method is not used, then the connection gets timed out as normal, but if it is used, a different timeout duration is used? |
@Yay295 if this keep-alive mechanism is not used, the client does not explicitly disconnect/reconnect the stream listening at all if there is no message received, since this is expected to not receive any message for a long time when there are no data changes. But if keep-alive mechanism is used, we can benefit from it - we expect at least keep-alive message to be received every interval by the SSE specs recommendation, thus we can use a timeout and disconnect/reconnect the stream listening when no message received by the timeout. |
In the current spec, any comment line is a keep-alive message. You appear to be advising that servers close connections more often, e.g. if they receive |
@domenic I am not advising any behavior change for servers for closing connections. A note to add, such mechanism is being used by some networking implementations products. |
I'll repeat the question then, in a more generic form. Currently, any line is a keep-alive message. Why would making a smaller set of messages cause keep-alives be useful, as opposed to the current spec? |
@domenic I will try to answer your question with a detailed example and comparison between current spec to the suggested solution.
Now let's see what the SSE client can do to handle the situation at 10:05:30 where no messages received at the SSE client in last few minutes. |
This is not true. Per the current spec, the keepalive mechanism is being used. All comments are keepalive messages. |
@liran2000 following https://whatwg.org/faq#adding-new-features would help here. |
@liran2000 is right. This is under-specified. The typical keepalive (assume 30 seconds) would mean that the client would reconnect if not receiving and message for 1.5 x the interval period (45 seconds seconds). But for the client to do this, the server first needs to inform the client about the keepalive interval. The proposed solution however doesn't really work imo, since it relies on the client to detect the interval based on 2 messages. If the connection already stalls after the first one, the client will wait forever on a stalled connection. I think this would be better solved with a response header, eg: |
As I stated, any message will keep the connection alive. If you would like to have your server communicate how often the client should send messages, you can do that using the SSE protocol itself. We don't need to add a header and get the browser or specification involved in the process. |
Isn't the eventsource the one that monitors the connection state and reconnects automatically? So the eventsource instance would need to know this information. Hence the only option is to make this part of the protocol, because the eventsource has no way of interpreting the data send over the event connection. This is mixing two different abstraction levels if this is to be done over the SSE connection itself. |
The EventSource instance doesn't need to know anything from the header. It knows that every time you send a message, it should keep the EventSource connection alive. If the server and client have a more specific protocol in mind, they can communicate that, but the automatic reconnection algorithm is very simple and doesn't need any extra information like "how often should the server send messages". If the server has specific constraints, then it is responsible for working out something with its clients for doing something beyond the spec's automatic reconnection logic. |
for reference, see: #8297 (comment) |
What it (the browser really) doesn't know is when it is not getting the keepalive/comments any more, to force a reconnect. The typical scenario is when the browser changes networks and the TCP connection becomes "stuck" ie. the client/browser can't always detect that it's dead and will not receive any more data, not until the TCP times out (and that can last for hours). |
@gdamjan the thing here is not that "it is not broken", because it clearly is. The thing is that for this team SSE is obsolete, and better alternatives are available, so they won't update. See #8297 (comment) |
"...authors can include a comment line (one starting with a ':' character) every 15 seconds or so."
This is helpful for SSE clients. The SSE client can read the keep-alive messages, and detect whether the connection is alive.
Thing is, since the keep-alive messages mechanism is not mandatory, the SSE client can use this condition only if the keep-alive mechanism is used, since when it is not used, it is a valid scenario that no message is received for a long time, even when the stream is alive.
Problem:
keep-alive message is not well-defined.
Suggested solution - edit:
authors can include a comment line (one starting with a ':' character) starting with ":keepalive" every 15 seconds or so.
This way, the SSE client can detect if keep-alive mechanism is used by checking if it received a keep-alive message as defined.
Opened PR for the solution:
The text was updated successfully, but these errors were encountered: