I should also say that the solution to this problem that we are going
towards in the Jetty API is to NOT make the ServletRequest available to the
application when it is accepting the websocket connection. Instead we make
a cutdown WebSocketHandshakeRequest available, which can wrap either a real
ServletRequest or be created from a MUX channel open.
cheers
On 14 August 2012 17:45, Greg Wilkins <gregw_at_intalio.com> wrote:
>
> 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.
>
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.