angular-cli: Invalid Host header after updating to 1.0.1

It’s indeed due to a security fix added lately to webpack-dev-server. You must start with ng serve --host your.ip.addr.ess

Until this gets resolved you can just change the following line in node_modules/webpack-dev-server/lib/Server.js (line 402):

if(this.disableHostCheck) return true;

change to

return true;

imho changing code under node_modules is the worst solution for this…

I’m reopening this issue, because it’s seems a major inconvienece to developers that the needed switches are not available in the CLI. To mitegate this issue, the ng server command needs to be able to port the --pubic <hostname> flag, and perhaps even the --disableHostCheck (although that last one really needs a severe warning, perhaps even a confirmation every time!)

@SanderElias there is a new option in webpack disableHostCheck that will also solve it. Can I set it if I’m using angular cli?

Seems like specifying --public <hostname> option for webpack-dev-server works for people behind proxies. Would it be possible to add it to ng serve?

The best solution available right now for users affected by this problem is to downgrade to 1.0.0.

@kktam, my current workaround is to add 0.0.0.0 <workspace>-<username>.c9users.io to /etc/hosts file, and to run ng serve -H <workspace>-<username>.c9users.io to serve the app.

Until this gets resolved you can just change the following line in node_modules/webpack-dev-server/lib/Server.js (line 402):

if(this.disableHostCheck) return true;

change to

return true;

this saved me after many hours of surfing for the solution

If you’re using the —host parameter to Angular-CLI, you obviously want the test server to serve on that address (possibly 0.0.0.0). It seems redundant to have to give additional parameters for that, even if it internally means that Angular-CLI needs to push extra parameters to the webpack dev server.

@AaronLangley Degrade to Angular-CLI 1.0.0 which has Angular V4, will solve problem. I am still figuring out the way for development purspose.

Maybe it related to? https://github.com/webpack/webpack-dev-server/issues/882

I don’t know what you guys are trying to do, but it seems that it has nothing to do with Angular CLI. You have some API routing problems as I can see, and you are probably just trying to hit the same URL where you got your Angular app served, which, obviously can’t handle your API requests as it’s not supposed to.

@filipesilva I upgraded another project to give this an another spin. Here are the results:

1 --host 0.0.0.0 always ends in invalid host header 2 --host <public ip> works as long as the client connects using the same ip-number, using a hostname doesn’t work 3 --host <name> works as long as the client connects using the same name. This might need changing the OS host files, or your local DNS server setup.

So, the problem is mostly the --host 0.0.0.0. When the --public switch is added, you can add a name, without changing anything in your system’s settings. I think this is preferable over my 3rth option.

Without the --public, it needs the disableHostCheck which might be a security issue, so this should not be enabled without an explicit setting and/or a warning.

If you mean that an existence of --host will configure webpack to ignore the host header, then it is fine. It’s not convenient to edit the command each time and write the ip address. The command is in package.json so it is common for all the team but each has a different address for the web server.

Even using ng serve --host 0.0.0.0 dosnt work anymore 😦

Or you can just give disableHostCheck : false, in webpackDevServer config in serve.js file in tasks folder of cli. node_modules/@angular/cli

@vivekamin - maybe a child object/section in .angular-cli.json that maps to webpack.config.js ?

Was just looking at this SO post for reactjs http://stackoverflow.com/questions/43619644/i-am-getting-an-invalid-host-header-message-when-running-my-react-app-in-a-we

@vivekamin edit your hosts file is the easiest. The dev server is not meant to be used in production. This a secutiry measure taken by the webpack team. There is little no nothing the CLI team can do, execpt from exposing the switched spoken about above!