+1 to that.
On Tue, Aug 14, 2012 at 2:47 AM, Greg Wilkins <gregw_at_intalio.com> wrote:
>
> 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.
>