tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: WebSockets in Tomcat 8 (proxy support and ssl handshake)
Date Wed, 22 May 2013 10:48:10 GMT
2013/5/22 Niki Dokovski <nickytd@gmail.com>:
>
>
>
> On Tue, May 21, 2013 at 3:15 PM, Niki Dokovski <nickytd@gmail.com> wrote:
>>
>>
>>
>>
>> On Mon, May 20, 2013 at 5:09 PM, Niki Dokovski <nickytd@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On Mon, May 20, 2013 at 3:45 PM, Niki Dokovski <nickytd@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, May 17, 2013 at 3:53 PM, Niki Dokovski <nickytd@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 17, 2013 at 3:35 PM, Mark Thomas <markt@apache.org>
wrote:
>>>>>>
>>>>>> On 17/05/2013 13:07, Niki Dokovski wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > Developing some sample apps with websockets and tomcat 8 revealed
>>>>>> > two
>>>>>> > issues I’d like to discuss here.
>>>>>> >
>>>>>> > 1.       There is no proxy support in the implementation of
>>>>>> > WebSocketContainer.connectToServer calls. While playing around
with
>>>>>> > the
>>>>>> > code it was relatively easy to add this in the implementation
with
>>>>>> > simple
>>>>>> > consideration of http.proxyHost and xxxxPort system properties;
>>>>>> > replacing
>>>>>> > host and port values which were obtained from path method parameter
>>>>>> > and
>>>>>> > making initial HTTP CONNECT message to the proxy. In this case,
do
>>>>>> > you
>>>>>> > think we can add proxy support here? I was thinking how to provide
>>>>>> > some
>>>>>> > kind of automation test as well, but no luck so far.
>>>>>>
>>>>>> Personally I dislike the global nature system properties for
>>>>>> configuration unless they are absolutely the only option.
>>>>>>
>>>>>> Since the WebSocket API has no way of setting a proxy at the moment,
>>>>>> system properties might be the only choice :(
>>>>>>
>>>>>> This is an issue you should raise with the WebSocket EG group. I
>>>>>> suggest
>>>>>> opening a Jira to request proxy support in a future version.
>>>>>> https://java.net/jira/browse/WEBSOCKET_SPEC
>>>>>
>>>>>
>>>>> Here is the issue:
>>>>> https://java.net/jira/browse/WEBSOCKET_SPEC-202
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> > 2.       So when I got my proxy tunneling in place (with the
CONNECT
>>>>>> > http
>>>>>> > request) I hit a tougher problem with SSL handshake implementation
>>>>>> > in
>>>>>> > WebSocketSslHandshakeThread. The SSL handshake was successful
while
>>>>>> > I was
>>>>>> > stepping with the debugger through the code and failed when
I  run
>>>>>> > the
>>>>>> > test. It should be some timing issue. This bit needs more debugging.
>>>>>> > Have
>>>>>> > you seen this before?
>>>>>>
>>>>>> No, but the SSL support for WebSocket clients hasn't been heavily
used
>>>>>> yet so there could still be some bugs to iron out. If you haven't
>>>>>> already, take a look at
>>>>>> TestWsWebSocketContainer.testConnectToServerEndpointSSL()
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks. I'll take a look at it.
>>>>>
>>>>
>>>>
>>>> Doing some debugging in the implementation of
>>>> AsyncChannelWeapperSecure.WebSocketSslHandshakeThread run()
>>>> revealed that by having small timeout (thread sleep) in "NEED_WRAP"
>>>> case, allows SSL handshake to complete successfully.
>>>> (This is still the case when there is a HTTP Proxy tunnel established
>>>> between Endpoints) This is not the solution for the problem, of course.
>>>> Here I attach some sysout logs with working and non-working flows.
>>>> 1. working example:
>>>> after sending initial message sleep the executing thread in "need_wrap"
>>>> case for little and you get following sequence
>>>> write: 154
>>>> write done: true
>>>> NEED_UNWRAP
>>>> read: 2357
>>>> read done: true
>>>> ....
>>>> SSL Handshake is OK
>>>>
>>>>
>>>> 2. non working example
>>>> write: 154
>>>> write done: true
>>>> NEED_UNWRAP
>>>> read: 1460 << much less bytes to consider
>>>> read done: true
>>>> ...
>>>> Exception
>>>>
>>>>
>>>> Any comments?
>>>
>>>
>>> getting closer as the error condition is caused by BUFFER_UNDERFLOW
>>> state. Will try to read again in this condition. Basically there is no
>>> enough bytes to construct the message in SSLEngine.
>>
>>
>> OK that does the trick. Here is a bug on the issue
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=54997
>> I'll try to polish a bit and send a small code snippet solving
>> BUFFER_UNDERFLOW case for discussion.
>>
>> cheers
>> Niki
>
>
> Here are two patches for http proxy support (WsWebSocketContainer) and
> buffer underflow (AsyncChannelWrapperSecure) fix respectively.  I'd like to
> ask for your comments.
>

Patches should be posted to Bugzilla.

The mailing list server strips attachments (unless they have proper
mime-type, etc. etc.)

> cheers
> Niki

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message