[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [servlet-dev] WebSocket and HttpSession
|
On 08/06/2023 19:27, Manfred Riem wrote:
Hi Mark,
Once the original request is upgraded that authentication should not be propagated by the Servlet layer.
If the developer wants to do something here, they should do that as part of the upgrade handler.
That is what they are doing. They obtain a reference to the HTTP session
during the upgrade process.
Which means for WebSocket the WebSocket folks should address this in the WebSocket specification if they choose to do so.
This does NOT belong to Servlet specification to solve.
I disagree.
Note this isn't a problem that I have first-hand experience of. I am
trying to represent the views of users who have expressed a need for
this feature.
The use case as I understand it is web applications that use:
- authentication
- a mix of HTTP and WebSocket in the UI
and want to align the lifecycle of the HTTP session and the WebSocket
session.
To put it another way, the developers want to be able to:
- close the WebSocket session when the HTTP session expires
- invalidate the HTTP session with the WebSocket session is closed
- ensure the WebSocket session remains open when the only activity is on
the HTTP side
- ensure the HTTP session remains valid when the only activity is on
the WebSocket side
The WebSocket and Servlet APIs have all the necessary hooks for
developers to implement the first three of these using their preferred
strategy. However, there is no way for developers to implement the
fourth requirement.
OK, that isn't strictly true. It can be done by getting the client to
send regular HTTP requests to keep the session active but that isn't
particularly efficient.
The aim of this proposal is to implement the minimal change that would
allow developers to simply implement the fourth requirement.
I'll also note that there have been some requests from Servlet
developers for some mechanism to keep the HTTP session alive that this
proposal would also meet.
Mark
Manfred
-----Original Message-----
From: servlet-dev <servlet-dev-bounces@xxxxxxxxxxx> On Behalf Of Mark Thomas
Sent: Thursday, June 8, 2023 12:44 PM
To: servlet-dev@xxxxxxxxxxx
Subject: Re: [servlet-dev] WebSocket and HttpSession
On 08/06/2023 17:10, Manfred Riem wrote:
Hi Mark,
Once you do a protocol upgrade one should not try to use anything that had to do with the original Servlet request.
If someone wants 'session' management then they should implement that as part of their WebSocket application.
Ideally, yes. Unfortunately that breaks down if access to the WebSocket endpoint is authenticated as the original HTTP request is then authenticated and that authentication process is linked to the HTTP session.
There are lots of different strategies for handling this. I'm not advocating for any one strategy. I am aiming for the minimal change to the Servlet and/or WebSocket specs that would allow developers to implement their strategy of choice.
Mark
Anyway my 2 dollars (inflation and all)
Thanks!
Kind regards,
Manfred Riem
-----Original Message-----
From: servlet-dev <servlet-dev-bounces@xxxxxxxxxxx> On Behalf Of Mark
Thomas
Sent: Thursday, June 8, 2023 10:58 AM
To: servlet developer discussions <servlet-dev@xxxxxxxxxxx>
Subject: [servlet-dev] WebSocket and HttpSession
Hi all,
I'd like to see if we can find a way to resolve a long standing WebSocket issue. The full detail can be found in this issue:
https://github.com/jakartaee/websocket/issues/175
The short version is that a WebSocket session that retains a reference to the Servlet HttpSession in place when the WebSocket handshake took place needs a way to indicate that it is using the session and that the session should not be invalidated for inactivity.
My proposal is to add the following method to HttpSession:
public void access()
Calling this method would update the last accessed time to the current time.
The circumstances in which a WebSocket application may call this method would be left as an application concern as different applications are likely to want to adopt different strategies.
Thoughts?
Mark
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
