New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Origin header should not be sent by client in handshake #615
Comments
@pavelbucek Commented |
@peraxel Commented According to RFC 6455, section 4.1 (Opening Handshake, Client Requirements): The use of origin header is described in other parts of the RFC as well. |
|
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. |
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 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 netty/netty#9673 |
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.
The text was updated successfully, but these errors were encountered: