2013/5/22 Niki Dokovski <nick...@gmail.com>: > > > > On Tue, May 21, 2013 at 3:15 PM, Niki Dokovski <nick...@gmail.com> wrote: >> >> >> >> >> 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 > > > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
