On Wed, May 22, 2013 at 1:48 PM, Konstantin Kolinko <knst.koli...@gmail.com>wrote:
> 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.) > Thanks: buffer underflow https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 http proxy https://issues.apache.org/bugzilla/show_bug.cgi?id=55006 > > > cheers > > Niki > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
