WebSocketClient is sending Transfer-Encoding & Content-Length in the same request.

[joakime]

Jetty version(s)
12.1.0 (HEAD)

Jetty Environment
ee11

Java version/vendor (use: java -version)
17, 21, 23

OS type/version
Linux

Description
org.eclipse.jetty.websocket.client.WebSocketClient fails on tests for org.eclipse.jetty.ee11.test.websocket.JettyWebSocketTest (found in the jetty-ee11-test-integration module).

See: https://jenkins.webtide.net/blue/organizations/jenkins/jetty.project/detail/PR-12583/36/tests
The above has DEBUG logging turned on.

One of the failures points at a bug in WebSocketClient handling of Request headers ...

org.eclipse.jetty.http.BadMessageException: 400: Transfer-Encoding and Content-Length
	at org.eclipse.jetty.http.HttpParser.checkViolation(HttpParser.java:371)
	at org.eclipse.jetty.http.HttpParser.parsedHeader(HttpParser.java:1145)
	at org.eclipse.jetty.http.HttpParser.parseFields(HttpParser.java:1358)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1705)
	at org.eclipse.jetty.server.internal.HttpConnection.parseRequestBuffer(HttpConnection.java:597)
	at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:379)
	at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1688)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
	at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:576)
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:391)
	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:150)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
	at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:480)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:443)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164)
	at java.base/java.lang.Thread.run(Thread.java:840)

I am unable to reproduce this issue on my local machine, only CI.

[joakime]

I was able to make it fail via the command line.

$ cd jetty-12.1.x
$ mvn clean install pl :jetty-ee11-test-integration
...(lots of output)...
[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   JettyWebSocketTest.testChatEndpoint:72 expected: <true> but was: <false>
[INFO] 
[ERROR] Tests run: 995, Failures: 1, Errors: 0, Skipped: 4
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  12:29 min
[INFO] Finished at: 2025-01-21T17:34:17-06:00
[INFO] ------------------------------------------------------------------------

with the output of the DEBUG found in ...

$ gedit jetty-ee11/jetty-ee11-tests/jetty-ee11-test-integration/target/surefire-reports/TEST-org.eclipse.jetty.ee11.test.websocket.JettyWebSocketTest.xml

[lachlan-roberts]

I don't think org.eclipse.jetty.http.BadMessageException: 400: Transfer-Encoding and Content-Length is the cause of the websocket test failure. From the logs I downloaded it looks like it was due to this Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 404 Not Found.

But I did find org.eclipse.jetty.http.BadMessageException: 400: Transfer-Encoding and Content-Length occurring 34 times in the log output so maybe there is an issue with that elsewhere.

In the logs it is never getting into any websocket server code to do the upgrade. I suspect the XmlBasedJettyServer used in the test is not actually deploying any websocket endpoints.

[joakime]

@olamy is there a way to disable the junit/surefire parallel testing on the command line of maven?
I'd like to eliminate that feature as a possible cause here.

[joakime]

But I did find org.eclipse.jetty.http.BadMessageException: 400: Transfer-Encoding and Content-Length occurring 34 times in the log output so maybe there is an issue with that elsewhere.

Yeah, I'm not saying that the "400: Transfer-Encoding and Content-Length" is the cause of the error with websocket, but it does point to a flaw in WebSocketClient (or HttpClient) to even allow that conflict in headers.

In the logs it is never getting into any websocket server code to do the upgrade. I suspect the XmlBasedJettyServer used in the test is not actually deploying any websocket endpoints.

I'll dig into that in the morning (if you want me to).