Connection declined and throws error

[ssk512]

Socket Connected: WebSocketSession[SERVER,to=PT30S,WSCoreSession@dd41b59{SERVER,WebSocketSessionState@7574a363{CONNECTED,i=NO-OP,o=NO-OP,c=null},[ws://10.194.5.32:8080/events/,null,false.[]],af=true,i/o=4096/4096,fs=65536}->JettyWebSocketFrameHandler@5877331f[org.eclipse.jetty.demo.EventSocket],JettyWebSocketFrameHandler@5877331f[org.eclipse.jetty.demo.EventSocket]]
java.nio.channels.ClosedChannelException
	at org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onEof(WebSocketSessionState.java:169)
	at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.onEof(WebSocketCoreSession.java:244)
	at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:478)
	at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.onFillable(WebSocketConnection.java:336)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
	at org.eclipse.jetty.io.SocketChannelEndPoint$1.run(SocketChannelEndPoint.java:101)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:412)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:381)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:268)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.lambda$new$0(AdaptiveExecutionStrategy.java:138)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:378)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:894)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1038)
	at java.base/java.lang.Thread.run(Thread.java:834)
Socket Closed: [1006] Session Closed

[lachlan-roberts]

@ssk512 Can you give more context to when you are getting this error. Is this just from running this example project with no changes?

This would happen if the client closed the connection before sending a WebSocket close frame.

[ssk512]

yes, I did not do any changes in Code , cloned and ran it. i am getting above error

[ssk512]

@lachlan-roberts how can i fix this issue?

[joakime]

I went ahead and added unit testing for the 10.0.x (256a5a1) and 11.0.x (416c2cc) branches.
It works as expected.

Even tested the websocket server with the browser's own javascript client (using the javascript console).
Even tested with the websocket server and websocket client on different machines talking over the network.

Can you provide detail on what you are doing? (there's not enough information provided by you to help you)
What OS? (be precise, include as much version detail as you can)
What JVM? (be precise, what vendor? what exact version? what update?)
Are you building from command line? what version of Maven?
Are you building and/or testing from the IDE? what IDE? what version?
What class (or classes) are you running?
How are you testing? (some step by step instructions would help)

[ssk512]

Phone are the clients and hosting the server from my localmachine to join phones
local machine details are given below
OS: Wndows 10
JVM -11.0.5
Maven 3
Eclipse -Eclipse IDE for Enterprise Java Developers., Version: 2019-09 R (4.13.0), Build id: 20190917-1200
Class: Eventserver.java
Through the postman able to connect, from the device not able to connect.

I tried with springboot- websocket, no issues but only in jetty facing the issue

[joakime]

Be accurate, and detailed please.

I am connecting phone device by websocket to control it. Phone device are the clients.

what phones?
what is the websocket client on those phones? (such as the library or software language)
what is the version of those websocket clients on those phones?
am i even correct in assuming the "phone device" is the websocket client?

OS: Wndows 10

What version of windows 10? (what update? what architecture?) - I ask this as certain Microsoft updates are known to cause issues with various programs. and architectures like ARM are also problematic with java at the moment.

JVM -11.0.5

What vendor? What architecture?
Where is this JVM running? on windows? on the phone?

Maven 3

What specific version of Maven 3.x? (be accurate, include the whole version, as certain version of Maven have problems)

Eclipse -Eclipse IDE for Enterprise Java Developers., Version: 2019-09 R (4.13.0), Build id: 20190917-1200

How did you test with Eclipse IDE?
What steps did you use?

Class: Eventserver.java

Which EventServer? (there are 2 of them in the code base)
Which branch on this project? (9.4.x? 10.0.x? 11.0.x?)

Through the postman able to connect, from the device not able to connect.

What's postman?
"The device" being what? the phone?
Is "the device" receiving websocket connections? or initiating websocket connections? or both?

What are the endpoint URIs?
Are you able to connect using something that isn't websocket?
Are you able to connect using http:// ?
Are you able to connect using https:// ?
Are you able to connect using ws:// ?
Are you able to connect using wss:// ?

What modifications have you made to the codebase to support connecting from different hosts / machines / devices? (you have to had changed something to support this scenario)

[joakime]

I tried with springboot- websocket, no issues but only in jetty facing the issue

This doesn't tell me anything I can work with.
We still don't even know what your first test you had issues was exactly.
Are you even testing the same thing? (like javax.websocket vs jakarta.websocket, or ws:// vs wss://, or websocket based on http/1.1 or http/2, or what websocket negotiation looked like)
Spring-Boot uses Jetty websocket, so it's unlikely to be a Jetty specific issue.
It could even be something as esoteric as you are using unsecured websocket with this projects configuration, and secured websocket on your spring-boot configuration, which various websocket libraries on phones do have issue with (as the unsecured websocket upgrade looks nefarious to various connection auditing/malware/security tools found on such devices). Heck, even in 2021, there are load balancers out there that will reject unsecured websocket upgrade as it mistakes the protocol as looking like a hacking attempt to that broken product.

[ssk512]

Request getting from Phone client

GET //10.198.8.78:8888/socket/ HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
Host: 10.198.8.78:8888
Origin: http://10.198.8.78:8888
Upgrade: websocket
Connection: close, Upgrade
Sec-WebSocket-Key: 9Y7WzchJwKR72PHdKrf7Mg==
Sec-WebSocket-Protocol: apigw-lws-protocol
Sec-WebSocket-Version: 13
User-Agent: devic8711.loads (dceb94bc3218)

Logs from server:

13:13:12.147 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannel - HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=6} onContentComplete
13:13:12.148 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannel - HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=7} onRequestComplete
13:13:12.149 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpInput - HttpInputOverHTTP@4cd6b38[c=0,q=0,[0]=null,s=STREAM] addContent EOF
13:13:12.150 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpConnection - HttpConnection@3a196f77[p=HttpParser{s=END,0 of -1},g=HttpGenerator@6722e595{s=START}]=>HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=8}<-SocketChannelEndPoint@64cd1ec2{/10.127.109.16:50964<->/10.198.8.78:8888,OPEN,fill=-,flush=-,to=74/30000}{io=0/0,kio=0,kro=1}->HttpConnection@3a196f77[p=HttpParser{s=END,0 of -1},g=HttpGenerator@6722e595{s=START}]=>HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=9} parsed true HttpParser{s=END,0 of -1}
13:13:12.151 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpConnection - releaseRequestBuffer HttpConnection@3a196f77[p=HttpParser{s=END,0 of -1},g=HttpGenerator@6722e595{s=START}]=>HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=9}<-SocketChannelEndPoint@64cd1ec2{/10.127.109.16:50964<->/10.198.8.78:8888,OPEN,fill=-,flush=-,to=74/30000}{io=0/0,kio=0,kro=1}->HttpConnection@3a196f77[p=HttpParser{s=END,0 of -1},g=HttpGenerator@6722e595{s=START}]=>HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=10}
13:13:12.152 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannel - HttpChannelOverHttp@31888b18{r=1,c=false,a=IDLE,uri=//10.198.8.78:8888/socket/,age=11} handle //10.198.8.78:8888/socket/
13:13:12.152 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannelState - handling HttpChannelState@638f3be5{s=IDLE a=NOT_ASYNC i=true r=IDLE w=false}
13:13:12.154 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannel - HttpChannelOverHttp@31888b18{r=1,c=false,a=DISPATCHED,uri=//10.198.8.78:8888/socket/,age=13} action DISPATCH
13:13:12.159 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.Server - REQUEST GET /socket/ on HttpChannelOverHttp@31888b18{r=1,c=false,a=DISPATCHED,uri=//10.198.8.78:8888/socket/,age=18}
13:13:12.159 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.handler.ContextHandler - scope null||/socket/ @ o.e.j.s.ServletContextHandler@402e37bc{/,null,AVAILABLE}
13:13:12.162 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.handler.ContextHandler - context=||/socket/ @ o.e.j.s.ServletContextHandler@402e37bc{/,null,AVAILABLE}
13:13:12.162 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.session - sessionHandler=org.eclipse.jetty.server.session.SessionHandler2041416495==dftMaxIdleSec=-1
13:13:12.162 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.session - session=null
13:13:12.165 [qtp2007331442-17] DEBUG org.eclipse.jetty.servlet.ServletHandler - servlet |/socket/|null -> org.eclipse.jetty.servlet.ServletHandler$Default404Servlet-79924b@734e8ffd==org.eclipse.jetty.servlet.ServletHandler$Default404Servlet,jsp=null,order=-1,inst=false
13:13:12.165 [qtp2007331442-17] DEBUG org.eclipse.jetty.servlet.ServletHandler - chain=null
13:13:12.195 [qtp2007331442-17] DEBUG org.eclipse.jetty.servlet.ServletHolder - Servlet.init org.eclipse.jetty.servlet.ServletHandler$Default404Servlet@78accbe5 for org.eclipse.jetty.servlet.ServletHandler$Default404Servlet-79924b
13:13:12.202 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannel - sendResponse info=null content=DirectByteBuffer@697e6a1f[p=0,l=323,c=32768,r=323]={<<<\n\n<me.../body>\n\n>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00} complete=true committing=true callback=Blocker@66d6d4d7{null}
13:13:12.207 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpChannel - COMMIT for /socket/ on HttpChannelOverHttp@31888b18{r=1,c=true,a=DISPATCHED,uri=//10.198.8.78:8888/socket/,age=66}
404 Not Found HTTP/1.1
Connection: close
Date: Wed, 18 Aug 2021 07:43:12 GMT
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1

13:13:12.214 [qtp2007331442-17] DEBUG org.eclipse.jetty.server.HttpConnection - org.eclipse.jetty.server.HttpConnection$SendCallback@19b9444[PROCESSING][i=HTTP/1.1{s=404,h=4,cl=-1},cb=org.eclipse.jetty.server.HttpChannel$CommitCallback@2535ffdc] generate: NEED_HEADER (null,[p=0,l=323,c=32768,r=323],true)@start
13:13:12.217 [qtp2007331442-17] DEBUG org.eclipse.jetty.http.HttpGenerator - generateHeaders HTTP/1.1{s=404,h=4,cl=-1} last=true content=DirectByteBuffer@697e6a1f[p=0,l=323,c=32768,r=323]={<<<\n\n<me.../body>\n\n>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
13:13:12.217 [qtp2007331442-17] DEBUG org.eclipse.jetty.http.HttpGenerator - Connection: close
Date: Wed, 18 Aug 2021 07:43:12 GMT
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1

[ssk512]

How can i accept only Upgrade from client request ->Connection: close, Upgrade

[joakime]

If the client is sending that, they are in violation of the WebSocket spec AND the HTTP spec at the same time.

Pragma: no-cache
Cache-Control: no-cache

Those 2 headers are not to be sent on a WebSocket Upgrade request.
They can falsely indicate to a caching proxy that the URL has some kind of caching rules, and this 1 instance is no-cache, making other instances cachable without the header.
These should be left out, and the caching proxy should instead rely on the Connection response header to determine caching.

Connection: close, Upgrade

The Connection header is only 1 token, always.
https://datatracker.ietf.org/doc/html/rfc7230#section-6.1

Using more than 1 token is effectively making only the first token looked at, all subsequent tokens are ignored.

These must be fixed, otherwise you are subject to bad behaviors by any HTTP intermediary, fixing it solely on the server is only a half-measure.

[sbordet]

@joakime I think ABNF in the section of RFC 7230 you reference is wrong, because previous paragraphs of the same section explicitly mention that the Connection header may have multiple values.

For example (from the same section):

A proxy or gateway MUST parse a received Connection header field before
a message is forwarded and, for each connection-option in this field,
remove any header field(s) from the message with the same name as the
connection-option

In jetty/jetty.project#6642 you actually suggest that we need to support multiple values, no?

[joakime]

project moved to https://github.com/jetty/jetty-examples