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. cheers Niki > > >> >>> >>> >>> >>> >>> >>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>>> >>>>> >>>> >>> >> >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
