ng serve behind HTTPS reverse proxy is failing to call https://localhost:4200

[jandsu]

Running ng serve behind an HTTPS reverse proxy is making requests on https://localhost:4200 when it should make them on http://localhost:4200

OS?

Ubuntu 16.04

Versions?

$ ng --version
angular-cli: 1.0.0-beta.11-webpack.9-4
node: 6.5.0
os: linux x64

Repro steps

1. ng new foo
2. cd foo
3. ng serve
4. Then I load the page on https://mywebserver.mydomain.org which is the page served by a reverse proxy
   ==> observe the network tab in Chrome developer tools, it keeps making requests on

https://localhost:4200/sockjs-node/info?t=1473926195156

which fail when the same URL starting with http:// works

---

I have an HTTPS reverse proxy in front (to be able to route API calls - it needs to be HTTPS because I use the geolocation API). Here is an excerpt of the NGINX configuration file.

$ cat /etc/nginx/sites-enabled/my-test
server {
    listen 443 ssl;
        location / {
        proxy_pass http://localhost:4200;
    }
    ssl_certificate /etc/nginx/ssl/myserver.crt;
    ssl_certificate_key /etc/nginx/ssl/myserver-private.key;
}

[jandsu]

FWIW, same issue with beta 14

$ ng --version 
angular-cli: 1.0.0-beta.14
node: 6.5.0
os: linux x64

[filipesilva]

Calls like https://localhost:4200/sockjs-node/info?t=1473926195156 are live reload pings, which I suppose just use the protocol the site is being served in (https:// in your case). Those aren't really meant to be changed.

Not sure what I can do to help in your case, it's not really a problem with the CLI I believe. I'll flag it for community help.

Maybe documentation for the proxy feature helps? #1896

[jandsu]

Please let me respectfully disagree. To me, this is a bug, not a question for support.
I understand that those are pings on live reload... the correct behavior would be either to :

• ping on http://localhost:4200 regardless of the hostname, port and scheme I use
• ping on the served page (scheme, hostname and port) by reading window.location without messing around with the URL

In other words, if the CLI is smart enough to replace the hostname with localhost and port with 4200, it should be smart enough to alter the scheme as well and systematically use http which the live-reload is serving... If it does not want to be that smart then it should let the window.location untouched.

[LeviRosol]

I'll second @jandsu with another use case.

We utilize vagrant for our development environment and typically use a local /etc/hosts entry to map a name to a local IP that vagrant uses (ie: myapp.dev). Because of this we're using nginx to host the app from the vm (like @jandsu is doing, but for ssl).

We use vagrant so that developers who are working on multiple projects do not have to manage a projects dependancies on their machines. So that means we run things like npm install and npm start from the vm itself.

What this results in is the app using localhost for it's generated files. So when the reload makes it down to the developer machine, it's trying to use localhost for the reload domain vs myapp.dev

It does appear that supporting a custom host for reload was intended in serve based on what's showing here:

angular-cli/packages/angular-cli/commands/serve.ts

Line 56 in 3aa61d5

name: 'live-reload-base-url',

I did try putting this to use, but it does not appear to have any impact on the host used in the reload script.

[LeviRosol]

via issue #1753 i found that by setting the host to 0.0.0.0 via --host 0.0.0.0 my issue goes away completely. I'm now running the app on a vagrant box @ localhost:4200, serving it up via an nginx proxy @ myapp.dev:1337 that I access from my base machine, and livereload seems to be making the request to myapp.dev:1337 correctly.

@jandsu I'm not sure if this will also resolve your issue since yours appears to be protocol vs host, but it's probably worth a shot.

Assuming my assumptions here are correct, it appears that the readme could use a little updating and / or the live-reload-base-url being fleshed out an utilized.

Hope this helps someone else!

[danktec]

I tried changing liveReloadPort to 443 with no apparent change on the client. I am reverse proxying https:// to 4200, so the desired behavior would be for the client to request a different port to what the server is hosting.

[mgol]

This is a Webpack issue, reproducible without Angular CLI. I created an issue, please vote for it (and add more info if you have some): webpack/webpack-dev-server#763.

EDIT: It turns out it's not fixable inside Webpack. On the other hand, PR #3952 does fix it for me so vote for it if you need this feature.

[xmeng1]

+1

[filipesilva]

Fixed by #3952.

[jandsu]

For anyone stumbling on this issue, there is indeed a --public-host option, however I personally don't wan't to commit the dev host name in the package.json command that runs ng serve since it is obviously different for each developer.

For now, I found this very dirty hack:

ng serve --public-host=httpfake://0.0.0.0:0/

It works fine with Angular CLI 1.4.1. It only works because some code in webpack checks if the protocol contains 'http'... (and not is http[s]).

The zero-port is required if you serve SSL on a non-standard port (which is my case, the 443 is used for the built version rather than ng serve).

The NGINX config that works for me is:

    # Proxy the Websocket connection to the Webpack server.
    location /sockjs-node/ {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        rewrite ^/(.*)$  /$1  break;
        proxy_set_header Host localhost;
        proxy_pass http://localhost:4200/;
    }

[tylercloke]

^ The above worked for me. I also had to set proxy_redirect default though.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}