Origin header should not be sent by client in handshake

[glassfishrobot]

Tyrus client is sending an origin header in the upgrade request. The value of the header is the host part of the websocket URL with scheme "http://". This does not really make sense and would say it's in fact misleading. Non-browser clients do not operate in a context where origin matters IMHO. According to the spec, the origin header is optional. The main reason for me reporting this issue is a problem I ran into with the Qlik Sense websocket based API which fails to handle the handshake with the Tyrus client due to the origin header value. I had to manually change the header value to get the handshake working.

[glassfishrobot]

• Issue Imported From: https://github.com/tyrus-project/tyrus/issues/615
• Original Issue Raised By:@peraxel
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@pavelbucek Commented And why is that Tyrus issue and not Qlik Sense issue?

[glassfishrobot]

@peraxel Commented Because it makes no sense to send an origin in non-browser scenarios like this and it causes more harm than good. Setting a fake origin like this may cause problems as we see in the Qlik Sense case. The Qlik Sense server knows the origin header is fake because it hasn't received any http/https requests from the source system prior to the WS handshake and therefore rightfully refuses to complete the handshake.

According to RFC 6455, section 4.1 (Opening Handshake, Client Requirements): "Additionally, if the client is a web browser, it supplies /origin/."

The use of origin header is described in other parts of the RFC as well.

[dmekhanikov]

I encountered a similar issue with a Spring WebSocket server and Tyrus client. Tyrus sends an URL with http:// specified as origin scheme in an upgrade request, while the connection is actually established over https. Spring makes this request fail unless you tweak allowed origins. I suggest removing this header from handshake requests or making the origin depend on whether a WSS or WS connection is being initiated.

[dadza]

Sending the Origin header results in Chromium 111 responding with 403 to DevTools Protocol requests (via https://github.com/kklisura/chrome-devtools-java-client) unless the origin is included with --remote-allow-origins=..

See https://bugs.chromium.org/p/chromium/issues/detail?id=1422444

That bug talks about Selenium with Netty4, which has the same problem. Netty5 no longer sets the Origin header (by default at least), see https://github.com/netty/netty/issues/9673