Skip to content

Host checking breaks multi-host proxy #893

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
AdamMcCormick opened this issue Apr 26, 2017 · 2 comments
Closed

Host checking breaks multi-host proxy #893

AdamMcCormick opened this issue Apr 26, 2017 · 2 comments

Comments

@AdamMcCormick
Copy link

AdamMcCormick commented Apr 26, 2017

I think this is a feature gap caused by a bug fix so make of it what you will. With the introduction of 2.4.3 (https://github.com/webpack/webpack-dev-server/releases/tag/v2.4.3), host headers are now explicitly being checked for all calls. That seems sane, but where before I could specify several hosts to proxy calls to:

devServer: {
    ...
    proxy: {
        '/**': {
            router: {
                'local.site1.com:8080': site1.com,
                'local.site2.com:8080': site2.com,
                ...
            },
        },
    },
    ...
}

I now have to add:

devServer: {
    ...
    disableHostCheck: true,
    ...
}

Or i get an invalid host message like seen in #882. I would expect that there would be a mechanism that would let me specify more than one public path since there is a means of specifying more than one public proxy. Perhaps make public take an array of paths?

@smitpsanghavi
Copy link

smitpsanghavi commented Apr 28, 2017

I have setup a local website in IIS and requests are routed to the webpack-dev-server on localhost:3000.

I have a mult-tenant SaaS app on which each tenant resides on a subdomain.
I cannot use *.mylocalsite.com in the devserver.public key of the config.
I have to hard-code subdomain.mylocalsite.com in the config and because of this I cannot access webpack-dev-server at subdomain1.mylocalsite.com

@shellscape
Copy link
Contributor

Fairly certain that #1012 and #899 resolve this issue. Please try upgrading and giving that a shot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants