Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
6.8.6
-
None
Description
When using a QWebSocket client to connect to server using an URI like "ws://[fe80::219:7cff:fe06:4f2%25eth3]/" the handshake request is declined by the server, due to a bad hostname.
The current implementation extracts the host and port part of the given URI to construct the request header `Host`. Which results in a invalid hostname, due to also containing the zone-id %eth3.
Steps to reproduce:
- Having a lighttpd as reverse proxy for a internal websocket server, configured to listen to any ipv6 address.
- Connect to the websocket endpoint with a slightly modified echoclient example which allows for passing the URI via command line
- Expect the connection to be established
- Actual observation: The connection does not get established
- Additionally: One can observe a 400 Bad Request being sent from the Server to the client, due to a invalid hostname
- Actual observation: The connection does not get established
If you need more information or configuration files or more details on how to reproduce this, please let me know.
We solved the issue with a minimal patch which removes the zone id from the URI part before it is used as the request header `Host`. See attached patch.
The patch was made for 5.14.2, but should also apply to 6.8.x as that part of the code looks the same at first glance.
I'll contribute the patch using the contribution guidelines as next.