On Mon, May 20, 2013 at 5:09 PM, Niki Dokovski <nick...@gmail.com> wrote:
> > > > 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. > 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 > >> >> >> >> >> >>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>> >>>> >>> >> >
