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
{{ message }}
Repository navigation
ng serve behind HTTPS reverse proxy is failing to call https://localhost:4200 #2123
$ ng --version
angular-cli: 1.0.0-beta.11-webpack.9-4
node: 6.5.0
os: linux x64
Repro steps
ng new foo
cd foo
ng serve
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
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.
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
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 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.
Reacted by Michał Gołębiowski-Owczarek, Heldt and Thomas LÉVEIL
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:
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.
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.
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.
Reacted by Jake Niemiec, Xin Meng, Jan Vorwerk and Mike Campbell
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/;
}
Reacted by Tyler Cloke, Hugo Benício and _________blcx
Activity
jandsu commentedon Sep 15, 2016
FWIW, same issue with beta 14
filipesilva commentedon Sep 21, 2016
Calls like
https://localhost:4200/sockjs-node/info?t=1473926195156are 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 commentedon Sep 21, 2016
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 :
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 commentedon Oct 18, 2016
I'll second @jandsu with another use case.
We utilize vagrant for our development environment and typically use a local
/etc/hostsentry 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 installandnpm startfrom the vm itself.What this results in is the app using
localhostfor it's generated files. So when the reload makes it down to the developer machine, it's trying to uselocalhostfor the reload domain vsmyapp.devIt 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
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 commentedon Oct 18, 2016
via issue #1753 i found that by setting the host to 0.0.0.0 via
--host 0.0.0.0my 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:1337that I access from my base machine, and livereload seems to be making the request tomyapp.dev:1337correctly.@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-urlbeing fleshed out an utilized.Hope this helps someone else!
danktec commentedon Dec 22, 2016
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 commentedon Jan 27, 2017
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 commentedon Feb 17, 2017
+1
filipesilva commentedon May 22, 2017
Fixed by #3952.
jandsu commentedon Oct 6, 2017
For anyone stumbling on this issue, there is indeed a
--public-hostoption, 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:
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:
tylercloke commentedon Apr 19, 2018
^ The above worked for me. I also had to set
proxy_redirect defaultthough.angular-automatic-lock-bot commentedon Sep 8, 2019
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.