Make live-reload (HMR) work out-of-the-box by directly exposing ports on the workspace URL

[jankeromnes]

Preamble

When you start an HTTP server in a Gitpod workspace, the port can be exposed to the public internet via a HTTPS proxy.

For example, in a workspace called red-fox-abcd, you can:

• Start some HTTP server on port 3000 (e.g. by running python3 -m http.server 3000)
• Click on "Open Browser" to open a Preview in a new tab

The Preview tab will have the URL https://3000-red-fox-abcd:443/.

Problems

The web server might expect to run on localhost:3000, but instead it is accessed via a different domain (3000-red-fox-abcd) and a different port (443, the default HTTPS port). But usually, the web server can be configured to accept other domains/ports, and to replace all links in the app with correct URLs, for example by:

• Setting the host filter to 0.0.0.0 instead of 127.0.0.1
• Writing a proxy configuration (http://localhost:3000 proxied behind https://3000-red-fox-abcd:443)

However, things get worse when the app wants to run a secondary web server (e.g. backend service, DB, API server, live-reload/HMR) on a different port:

• Start secondary server on port 3001
• Suddenly, the web app from port 3000 gets very confused: It tries to access 3000-red-fox-abcd:3001 instead of 3001-red-fox-abcd:443

The fixes there are a bit trickier, or sometimes even impossible. Some workaround we've found to occasionally work are:

• Configuring the correct domain & port for the secondary server, if possible (and sometimes it's tricky to make the secondary server still run on port 3001 while making the front-end use a port that is not 3001)
• Some frameworks allow proxying secondary servers via the main server (e.g. Angular) but often "proxying" is not even implemented in development modes (where it's expected you can just use localhost)
• Implementing support for secondary server proxy configs into the framework and sending a Pull Request(!)
• As a last resort, "hack" the framework code with sed after installing it in the workspace: https://github.com/sveltejs/svelte/pull/4277/files#diff-370a022e48cb18faf98122794ffc5ce775b2606b09a9d1f80b71333425ec078eR7

Explanation

Probably the core problem here is that Gitpod's proxy behavior is unique and unexpected for most web servers: It encodes the port into the domain, causing a double confusion for web servers (different domain & different port than what's running on localhost, or even on the proxied primary web service).

Solution

We can simplify setups and remove the need for awkward workarounds by making the Gitpod proxy behavior a little more "standard", i.e. by exposing server ports as actual ports and not as domains:

• 3000-red-fox-abcd:443 --> red-fox-abcd:3000
• 3001-red-fox-abcd:443 --> red-fox-abcd:3001

This means only the domain needs to be configured/accepted by web servers, and it's the same domain even for secondary servers (so a framework randomly exposing & accessing different ports will most likely just work out-of-the-box without mad configuration wrangling).

[shaal]

+1 for this feature

@rfay It look like it can resolve your request in #3184

[rfay]

Yeah, this might be a duplicate of #3184

The key difference is that one is explicitly about generic tcp port exposure, and this one could be handled with http proxy it appears.

[jankeromnes]

Hmm, the issues definitely seem related, but to me they're not quite the same:

• This issue is about exposing HTTP ports as <ws-id>.gitpod.io:<port> instead of <port>-<ws-id>.gitpod.io:443, but still behind the HTTPS proxy
• Please allow exposing TCP ports #3184 is about exposing TCP ports, probably also at <ws-id>.gitpod.io:<port>, but without the HTTPS proxy

Then, SSH access will probably require a directly-exposed port too (#1781) and there have been a few requests for other non-HTTP ports to be exposed (e.g. MySQL: #736), which are probably all TCP-based.

[davidwindell]

https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/

[erasmuswill]

What about having a domain such as ssl-.gitpod.io: for the HTTPS-proxied version and .gitpod.io: for TCP

[jankeromnes]

💭 Thought: The Local Companion app might make many localhost-assuming workflows just work out-of-the-box as well (e.g. HMR / live-reload), since you will be developing on your actual localhost.

[akosyakov]

Yes, it should resolve this issue, I hope to teach VS Code Web to see localhost tunnels 🤞 and given that required ports are available on local machine it should just work.

[akosyakov]

We just announced preview version of Gitpod local companion which allows to tunnel any tcp port: https://www.gitpod.io/blog/local-app please try and give us feedback 🙏🏻

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[akosyakov]

by now you can use the local app to tunnel localhost and VS Code Web knows about it, you can also use VS Code Desktop.