There is a rewrite feature that allows requests to a firebase static site to be written to a cloud run function:

"hosting": {
  ...
  "rewrites": [{
    "source": "/api",
    "run": {
      "serviceId": "my-api",
    }
  }]
}

However it is unclear if this is intended to work with websocket requests.

I can confirm that the rewrite is partially working as the websocket request doesn't get caught by the ** rewrite rule. Testing with postman it seems that the request returns "404 Not Found" to the initial http upgrade request instead of "101 Switching Protocols".

Connecting a websocket directly to the cloud run domain works fine.

CodePudding user response：

Firebase Hosting can be likened to a CDN rather than a basic proxy. When a user makes a request against it, the response is handled according to the documented order for response handling and each request is handled as a HTTP(S) request.

If using rewrites to serve dynamic content from a Cloud Function or Cloud Run, the request is checked against Firebase Hosting's internal caching CDN, and then forwarded on to the source if the stored response is not available or has expired. From my understanding of how this works, these steps are implemented with multiple internal requests rather than streaming the client's request through directly.

Instead you would mask Cloud Run with a custom domain (at time of writing this is in preview) such as ws.yourapp.com so that you skip over Firebase Hosting's CDN but still have a user-friendly URL. While you could also redirect yourapp.com/api to ws.yourapp.com with a rewrite/redirect rule, redirection must be supported by the web socket client you are using (as its not a required part of the web socket spec).