You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand this is a bug report and questions should be posted in the Community Forum
I searched issues and couldn’t find anything (or linked relevant results below)
Link to runnable example
No response
Steps to reproduce
Regarding the way websockets work for 3rd-party providers, there is a function called getSocketHost used in the companion-client to get the hostname to start the websocket connection.
The getSocketHost does not consider a full domain starting with www to generate the hostname. This behaviour may create a bug on domains that use page redirection for root domains.
Considering the Companion server is hosted in the URL https://www.example.com/companion
Considering there is a DNS page redirection that redirects every example.com to www.example.com
So the frontend Uppy application (through RequestClient) will try to create a websocket connection to: wss://example.com/companion/api/123456
Expected behavior
The RequestClient should be able to create the ws URL to wss://www.example.com/companion/api/123456
Actual behavior
The RequestClient creates the ws URL to wss://example.com/companion/api/123456
Considering the DNS rule to redirect root domain to full domain (with the www), the ws attempt connection will fail as DNS will reply with 3xx redirection while the request was expecting for 101 Switching Protocols to establish the ws connection
The text was updated successfully, but these errors were encountered:
@Murderlon I'm not sure if I fully understand you.
As stated, the companionUrl is https://www.example.com/companion.
The getSocketHost function removes the www from the URL to create the socket URL. Check the Regex and how it extracts the host from the companionUrl: https://github.com/transloadit/uppy/blob/main/packages/%40uppy/utils/src/getSocketHost.ts
So, the URL created in RequestClient becomes wss://example.com/companion/api/123456. I do not have control over how the websocket URL is created
Initial checklist
Link to runnable example
No response
Steps to reproduce
Regarding the way websockets work for 3rd-party providers, there is a function called
getSocketHost
used in the companion-client to get the hostname to start the websocket connection.The
getSocketHost
does not consider a full domain starting withwww
to generate the hostname. This behaviour may create a bug on domains that use page redirection for root domains.Considering the Companion server is hosted in the URL
https://www.example.com/companion
Considering there is a DNS page redirection that redirects every
example.com
towww.example.com
So the frontend Uppy application (through
RequestClient
) will try to create a websocket connection to:wss://example.com/companion/api/123456
Expected behavior
The RequestClient should be able to create the ws URL to
wss://www.example.com/companion/api/123456
Actual behavior
The RequestClient creates the ws URL to
wss://example.com/companion/api/123456
Considering the DNS rule to redirect root domain to full domain (with the
www
), the ws attempt connection will fail as DNS will reply with 3xx redirection while the request was expecting for 101 Switching Protocols to establish the ws connectionThe text was updated successfully, but these errors were encountered: