Automatic SSE reconnects shouldn’t extend the session
As per the EventSource specification, browsers automatically reconnect to a Server-sent events endpoint if the connection closes.
Clients will reconnect if the connection is closed; a client can be told to stop reconnecting using the HTTP 204 No Content response code.
Since these reconnects are automatic (like WebSocket heartbeats discussed in #548), they don’t indicate user activity and arguably shouldn’t extend the session. Allowing them to extend it indefinitely could be considered a security issue. Conversely, because they are long lived, these requests can also prematurely end a session (see #1280).
For reference, Spring’s SSE support comes in the form of SseEmitter.
The presence of the Last-Event-ID request header is a strong signal that an SSE request is an automatic reconnect, but that’s only a heuristic. Since Microsoft never bothered implementing EventSource, polyfills are have been popular, and they often use a query parameter to identify the last event received.
Rather than try to solve the problem perfectly, you might consider a flexible solution that allows developers to essentially turn off session extension (updating the last-access time) for certain requests. SSEs aren’t the only automatic requests web applications might send, after all.
One possible way to offer that flexibility might be to let us annotate a request mapping with a new @AutomaticRequest annotation. I’m sure that any mechanism you choose will be better than what’s currently required—writing a custom filter and/or SessionRepository implementation. Thanks for considering it.
I’m using 2.0.8. Issue also exists in master.