WebSocket connection rejected with HTTP 400 on Zen while succeeded on Safari

bzm

FREEOP

a month ago

I believe the issue already posted this thread but no activity and archived.

I'm facing similar issue where WebSocket connection is rejected with HTTP 400 on Zen (Firefox-based) while succeeded on Chrome and Safari.

I gather the information from different browser during WebSocket handshake.

Zen request headers

GET /ws HTTP/1.1
Host: backend-development-6b99.up.railway.app
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Sec-WebSocket-Version: 13
Origin: https://hoppscotch.io
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: mEQ2bldXGSQWYnCYSbmeww==
Sec-GPC: 1
Connection: keep-alive, Upgrade
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: websocket
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Chrome request headers

GET wss://backend-development-6b99.up.railway.app/ws HTTP/1.1
Host: backend-development-6b99.up.railway.app
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Upgrade: websocket
Origin: https://hoppscotch.io
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Sec-WebSocket-Key: tXLl4QqBh1KClcgZSnzNow==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

Notice the difference in the Connection headers:

# Zen/Firefox
Connection: keep-alive, Upgrade
# Chrome
Connection: Upgrade

I did a little bit logging and the Connection headers is missing from Zen/Firefox and exists in Chrome. This is align with the mentioned thread above that Connection: keep-alive, Upgrade is causing this and the request is reach the application, but perhaps railway proxy is strip them down when using Connection: keep-alive, Upgrade.

Perhaps start fixing the proxy?

8 Replies

Status changed to Awaiting Railway Response Railway • 27 days ago

bzm

FREEOP

a month ago

I did test on my local and previously run the application in vultr behind caddy, it works fine for all browser including Firefox. So its a high chance that the railway proxy is strip the headers down.

brody

EMPLOYEE

a month ago

Thank you for the additional report, it helps us determine the impact, so as mentioned previously, we will be looking into this.

Status changed to Awaiting User Response Railway • 27 days ago

bzm

FREEOP

22 days ago

Any update @brody?

Status changed to Awaiting Railway Response Railway • 22 days ago

brody

EMPLOYEE

21 days ago

This is on our list to address, but to be transparent, it currently affects a very small number of users, so it is low priority at this time.

Status changed to Awaiting User Response Railway • 21 days ago

bzm

FREEOP

21 days ago

Fair enough, glad to hear that the issue is on the list.

Status changed to Awaiting Railway Response Railway • 21 days ago

bzm

FREEOP

19 days ago

Seems to be working now, thanks.

brody

EMPLOYEE

19 days ago

Uh well I'm glad its working for you, but I've just checked, we have not put in any fixes for this, and my test I had to reproduce this is still failing.

bzm

FREEOP

18 days ago

I'm checking that the header still the same in the same browser. I guess I'll take the W for now but worry it might be broken at some point, still looking forward the fixes. Thanks

Welcome!