Skip to content

Websockets fails when studio is behind a reverse proxy #572

@OliverEvans96

Description

@OliverEvans96
  1. Prisma version (prisma -v or npx prisma -v):
@prisma/cli          : 2.10.1
@prisma/client       : 2.10.1
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine 7d0087eadc7265e12d4b8d8c3516b02c4c965111 (at node_modules/@prisma/engines/query-engine-debian-openssl-1.1.x)
Migration Engine     : migration-engine-cli 7d0087eadc7265e12d4b8d8c3516b02c4c965111 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core 7d0087eadc7265e12d4b8d8c3516b02c4c965111 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary        : prisma-fmt 7d0087eadc7265e12d4b8d8c3516b02c4c965111 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Studio               : 0.304.0
  1. Logs from Developer Tools Console or Command line, if any:
WebSocket connection to 'wss://my.domain.com/' failed: Error during WebSocket handshake: Unexpected response code: 302
  1. Does the issue persist even after updating to the latest prisma alpha? (npm i -D @prisma/cli@dev)
    Yes

  2. Prisma schema (if relevant):
    N/A


Related to #168 - I'm serving prisma studio at https://my.domain.com/subpath/to/studio just using prisma studio from the command line via docker/k8s/nginx. Studio is attempting to make a websocket connection to wss://my.domain.com/, which is being redirected to wss://my.domain.com/home, hence the response code 302 in the error message above (Section 2).

I was able to resolve the issue by patching the minified script @prisma/cli/build/public/serverBus.js as follows:

Before:

connect()const{protocol:e,host:t}=window.location,n=`${e.replace(/http/,"ws")}//${t}`;

After:

connect()const{protocol:e,host:t,pathname}=window.location,n=`${e.replace(/http/,"ws")}//${t}${pathname}`;

So basically, the request URL was being determined only by the host (which makes sense since you've so far intended this to always be run on localhost directly without a reverse proxy). To support reverse proxies, it's just necessary to consider the full path in the connect function.

Thanks,
Oliver

Metadata

Metadata

Assignees

Labels

kind/improvementAn improvement to existing feature and code.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions