Danny,
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 <danny.coward_at_oracle.com> wrote:
> Hi folks,
>
> 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
> - HttpSession
> - ServletContext
> - 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 !
>
> - Danny
>
>
>
>
>
>
>
>
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.