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.

Start with the EventSource specification and Spring's SseEmitter reference, then inspect how session access is currently updated. Compare the existing custom filter and SessionRepository approaches described in the issue. Done should be a documented, flexible way for applications to prevent selected automatic requests from extending the session.