I'd also like to add Multiplexing support, because MUX is definitely coming to websocket sooner or later.
The issue with mux is that unlike the original handshake, there is no real HTTP request available when a new channel is opened on a muxed websocket connection.
The MUX protocol will provide all the headers as-if the HTTP handshake had been sent, but it is unclear until we see browser implementations if this will really be all-the-headers? eg including cookies and auth?
The problem we have to avoid is allowing any state from the servlet/EE context of the original handshake/connection leak into a newly opened channel, as the MUX may be done by a proxy and may be mixing channels from different users on different browsers. Creating the correct EE context for MUX connections is probably going to need a lot of container involvement.
cheers--On 10 August 2012 09:59, Danny Coward < " target="_blank"> > wrote:
One of the larger items remaining to work on is how the Web Socket API integrates-with/works-when-deployed-in web containers and in the Java EE platform.
So I wanted to get out a few simple ideas to stimulate discussion on that topic.
1) Integration with web security
- it should be possible to declare a web socket's security context: an endpoint's required authentication scheme, the user-roles that can access it, whether transport encryption must be on on/off.
- developers should have access to the security context at runtime (current API does some, not all of this).
2) Web Socket sessions and Http Sessions
- see my last email on 'Multithreading Options' for four suggested scenarios on that. I'm sure there are more.
3) Using EE components to create Web Sockets
- it should be possible to create a web socket endpoint using a stateless session or singleton EJB, or using a CDI managed bean
4) Here are some useful objects to inject into web socket applications:-
a) into web socket endpoints
- ServerContainer (see WebSocketAPI v003)
- EndpointConfiguration (see WebSocketAPI v003)
- list of active Sessions (see WebSocketAPI v003)
b) into a MessageHandler
- current Session (see WebSocketAPI v003)
- Remote (see WebSocketAPI v003)
5) Packaging model
- should be able to deploy websocket application classes into a WAR
- they should live in the usual spot WEB-INF/classes and/or WEB-INF/lib
I'd welcome other ideas or comment on all of these !
Greg Wilkins < " target="_blank"> >
Developer advice and support from the Jetty & CometD experts.
[jsr356-experts] Re: Some ideas on Web Sockets in the web container and in Java EE