8000 curl duplicates Sec-WebSocket-* headers on ws scheme urls · Issue #17170 · curl/curl · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

curl duplicates Sec-WebSocket-* headers on ws scheme urls #17170

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.

Sign up for GitHub

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

Jump to bottom
Closed
8000
sbernatsky opened this issue Apr 24, 2025 · 2 comments
Closed

curl duplicates Sec-WebSocket-* headers on ws scheme urls #17170

sbernatsky opened this issue Apr 24, 2025 · 2 comments
Labels
WebSocket

Comments

@sbernatsky
Copy link

I did this

curl command generates its own Connection, Sec-WebSocket-Version, and Sec-WebSocket-Key headers for ws scheme urls even if they are provided via -H parameter:

$ curl -v -H "connection: upgrade" -H "upgrade: websocket" \
     -H "sec-websocket-extensions: permessage-deflate; client_max_window_bits" \
     -H "sec-websocket-key: Eq59gnzLPI6BgugauKvxNQ==" \
     -H "sec-websocket-version: 13" \
     "wss://some.host/ws/some"
> GET /ws/some HTTP/1.1
> User-Agent: curl/8.13.0
> Accept: */*
> Connection: Upgrade
> Sec-WebSocket-Version: 13
> Sec-WebSocket-Key: E114pfFpslS1hOOAM7d0zA==
> sec-websocket-extensions: permessage-deflate; client_max_window_bits
> connection: upgrade
> upgrade: websocket
> sec-websocket-key: Eq59gnzLPI6BgugauKvxNQ==
> sec-websocket-version: 13
> 
< HTTP/1.1 400 could not parse HTTP Sec-WebSocket-Version header '13,13' in opening handshake request
< Server: nginx
< Date: Thu, 24 Apr 2025 14:55:48 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
* Refused WebSockets upgrade: 400
< 
* closing connection #0
curl: (22) Refused WebSockets upgrade: 400

This results in 400 Bad Request response.

However for http scheme those headers are not generated and 101 response is returned back:

$ curl -v -H "connection: upgrade" -H "upgrade: websocket" \
     -H "sec-websocket-extensions: permessage-deflate; client_max_window_bits" \
     -H "sec-websocket-key: Eq59gnzLPI6BgugauKvxNQ==" \
     -H "sec-websocket-version: 13" \
     "https://some.host/ws/some"

> GET /ws/some HTTP/1.1
> User-Agent: curl/8.13.0
> Accept: */*
> sec-websocket-extensions: permessage-deflate; client_max_window_bits
> connection: upgrade
> upgrade: websocket
> sec-websocket-key: Eq59gnzLPI6BgugauKvxNQ==
> sec-websocket-version: 13
> 
< HTTP/1.1 101 Switching Protocols
< Server: nginx
< Date: Thu, 24 Apr 2025 15:07:28 GMT
< Connection: upgrade
< Upgrade: WebSocket
< Sec-WebSocket-Accept: H/+nMIUGFqohOsBk3wJgXfAbPSo=
< Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
<

I expected the following

I expect that regardless of the url scheme used the headers won't be duplicated in request if they are provided in extra parameters.

curl/libcurl version

curl 8.13.0 (x86_64-apple-darwin) libcurl/8.13.0 OpenSSL/3.4.1 zlib/1.3.1 brotli/1.1.0 zstd/1.5.7 c-ares/1.34.4 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.65.0 nghttp3/1.8.0
Release-Date: 2025-04-02
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Largefile libz NTLM PSL SSL SSLS-EXPORT threadsafe TLS-SRP TrackMemory UnixSockets zstd

operating system

MacOS
@bagder
Copy link
Member
bagder commented Apr 24, 2025

It is of course a little like asking for trouble to provide that extensive set, but sure it should certainly make a best-effort. The sec-websocket-extensions passed in like that will still break existing ws for curl.

@sbernatsky
Copy link
Author

It is of course a little like asking for trouble to provide that extensive set, but sure it should certainly make a best-effort. The sec-websocket-extensions passed in like that will still break existing ws for curl.

Same problem without sec-websocket-extensions header:

$ curl -v -H "connection: upgrade" -H "upgrade: websocket" \
     -H "sec-websocket-key: Eq59gnzLPI6BgugauKvxNQ==" \
     -H "sec-websocket-version: 13" \
     "wss://some.host/ws/some"
> GET /ws/some HTTP/1.1
> User-Agent: curl/8.13.0
> Accept: */*
> Connection: Upgrade
> Sec-WebSocket-Version: 13
> Sec-WebSocket-Key: Yc8UmTqyQIEZLyA1xmBNow==
> connection: upgrade
> upgrade: websocket
> sec-websocket-key: Eq59gnzLPI6BgugauKvxNQ==
> sec-websocket-version: 13
> 
< HTTP/1.1 400 could not parse HTTP Sec-WebSocket-Version header '13,13' in opening handshake request
< Server: nginx
< Date: Thu, 24 Apr 2025 15:50:05 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
* Refused WebSockets upgrade: 400
< 
* closing connection #0
curl: (22) Refused WebSockets upgrade: 400

bagder added a commit that referenced this issue Apr 25, 2025
@bagder
ws: fix the header replace check
e0f8b36 
It passed in the wrong header length to the check function, which made
it do duplicated headers in cases where the user provides its own set.

Reported-by: sbernatsky on github
Fixes #17170
@bagder bagder mentioned this issue Apr 25, 2025
Closed
@bagder bagder closed this as completed in 991c30d Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
WebSocket
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

ws: fix the header replace check curl/curl
2 participants
@bagder @sbernatsky
0