On Mon, May 20, 2013 at 3:45 PM, Niki Dokovski <nick...@gmail.com> wrote:
> > > > On Fri, May 17, 2013 at 3:53 PM, Niki Dokovski <nick...@gmail.com> wrote: > >> >> >> >> On Fri, May 17, 2013 at 3:35 PM, Mark Thomas <ma...@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. > > > > > > >> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >> >
