quorumcontrol / tupelo-wasm-sdk

(ALPHA) A wasm-based TypeScript sdk that does not require the RPC server.
MIT License
9 stars 1 forks source link

SDK doesn't work on Firefox #56

Open vrde opened 5 years ago

vrde commented 5 years ago

This is a known issue, anyway I'd like to start a thread about it.

IMO the problem is related to the WebSocket connection since I see this error Firefox can’t establish a connection to the server at wss://3-123-96-106.ssl.quorumcontrol.com/ipfs/16Uiu2HAmLMQwov4gUfMYGA8Joiob7A2j9gKRTMzBpUgaMJchoAGd.

Firefox request and headers:

GET /ipfs/16Uiu2HAmN9ZudXfmPwqLqLBUDW9kyomsbADhU2ASKKYYJT45FPyi HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Cache-Control: no-cache
Connection: keep-alive, Upgrade
Host: 3-221-84-48.ssl.quorumcontrol.com
Origin: https://vrde.github.io
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: K87Lkk5IuY+3TtiM0jzAZQ==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Chromium request headers:

GET wss://3-123-96-106.ssl.quorumcontrol.com/ipfs/16Uiu2HAmLMQwov4gUfMYGA8Joiob7A2j9gKRTMzBpUgaMJchoAGd HTTP/1.1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,de;q=0.8
Cache-Control: no-cache
Connection: Upgrade
Host: 3-123-96-106.ssl.quorumcontrol.com
Origin: https://vrde.github.io
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: aOG+PdBB4w+vBUrNtSovEQ==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/78.0.3904.70 Chrome/78.0.3904.70 Safari/537.36

One thing to notice is that the Sec-WebSocket-Extensions differs on the two browsers:

I see the same difference if I try to connect to an echo WebSocket with new WebSocket("wss://echo.websocket.org").

I've found this comment that might be related:

In FF the offer does not include the client_max_window_bits parameter so If you are setting the clientMaxWindowBits option to a number in the configuration, the offer is not acceptable and the connection is closed.

I'm starting to think that the WebSocket server has or misses some options that are creating issues with Firefox.

tobowers commented 5 years ago

Hmm - the websocket server is in Go and not ws, so maybe we need to configure ws somehow to add client_max_window_bits

vrde commented 5 years ago

Yeah, I mentioned that issue because it shows how Firefox has stricter requirements on what is a valid WS connection.

Unfortunately Firefox is not explicit in what's the actual issue, so we might lose some time in guessing.

But again, I'm optimistic that it's just a header issue :crossed_fingers: