Re: [jetty-dev] Further information about my problems with the Jetty 8.1

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

Tomas,

Good bug report! 

Can you file it at bugs.eclipse.org (under RT > Jetty)

Interesting indeed.

I'll add some test cases today to see if I can trigger this.

- Joakim

On Fri, Oct 26, 2012 at 7:56 AM, Tomas Normark <tomas@xxxxxxxxx> wrote:

Hi Joakim,

I have now gotten a bit further in debugging why I can not get a Jetty 8.1.7
WebSocket client to connect to a Tomcat server. Since I am running both the
client and the server on the local machine I could not get any network traffic
debugging tools to pick up what was sent between the client and the server.

Instead I downloaded the source code for both Jetty and Tomcat to be able to
debug into the code and see what was sent.

In HttpParser.parseNext in Jetty I can stop and look at the contents of
_buffer after the call to getHeaderBuffer() to see the answer that is returned
from the server after the upgrade request has been sent from the client.

This is the answer I get when using a Jetty server (and everything works fine):

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: NXxjx+Gjw12vy0k9t/BPIZGdRhc=

This is the answer I get when using a Tomcat server (and a websocket
connection is not established):

HTTP/1.1 101 Switching Protocols
Server: Apache-Coyote/1.1
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Accept: OAnlgFR8+YIsaqt2aOVkL/bdQpk=
Transfer-Encoding: chunked
Date: Fri, 26 Oct 2012 11:11:38 GMT

As you can see the big difference is that the Tomcat server returns the
answer with Transfer-Encoding set to chunked. When debugging through
HttpParser.parseNext in Jetty I see that this makes _state being set to
HttpParser.STATE_CHUNKED_CONTENT before the method returns.

If the server is a Jetty server _state is instead set to HttpParser.STATE_END

This means that the call to _parser.isComplete() in the while-clause in
the beginning of the handle() method in WebSocketClientFactory will return
true when the server is a Jetty server but false when the server is a
Tomcat server.

So for the case with the Jetty server the while loop is ended and the
code can continue to run with the line after it setting up the WebSocket
connection.

However for the case with the Tomcat server it runs forever in the while-loop
in the begining of handle() method in WebSocketClientFactory.
Each time in the while-loop it makes new calls to _parser.parseAvailable().
However nothing more is available to read from a server response and
_state never gets the set to HttpParser.STATE_END to make the while-loop end.

As far as I can see the problem is that Tomcat sets Transfer-Encoding to
chunked but everything is returned in ONE chunk. This is what causes the
Jetty client to be confused during the initial handshake and never to
establish the WebSocket connection.

Do you think my analysis is correct and is this something that would be worth
submitting as a bug report to bugs.eclipse.org ?

Do you know about any possible workaround for this, such as forcing Tomcat to
not send chunked answers or making Jetty handle them properly in this case?

Please do not hesitate to ask for more information if anything is unclear
in what I have written above.

Best regards,

Tomas Normark