Webpack-dev-server: Hot reloading requests to localhost or 127.0.0.1 are blocked

[ntucker]

Do you want to request a feature or report a bug?

bug

What is the current behavior?
hot-updates (in form of hot-update.json) requests are blocked by same origin check when using localhost or 127.0.0.1 and a different port for html and webpack (js, etc)

If the current behavior is a bug, please provide the steps to reproduce.

• serve html on one port (say 8000)
• run webpack-dev-server on another (say port 3000)
  
  
  
  • make sure you're running it in hot mode
  
  
• load site (everything works fine)
• change something that triggers hot-reload
• see the failure in dev console due to cross origin blocking.
  
  
  
  • you can see no Access-Control-Allow-Origin set on the hot-update.json even though the other resources were served with a Access-Control-Allow-Origin set
  
  

What is the expected behavior?
Requests to localhost or 127.0.0.1 are not blocked. (Access-Control-Allow-Origin is set to the port of html - in this case 8000)

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention your webpack and Operating System version.
webpack-dev-server: 2.4.5
webpack: 2.4.1

[badtant]

I'm having the same issue and not sure what to do to solve it.

[badtant]

this got it working for me

disableHostCheck: true,
headers: { 'Access-Control-Allow-Origin': '*' }

[davidgoli]

see https://github.com/webpack/webpack-dev-middleware/releases/tag/v1.10.2 for an explanation

[ntucker]

@davidgoli According to https://github.com/webpack/webpack-dev-server/releases/tag/v2.4.3

• Requests to localhost or 127.0.0.1 are not blocked.
• added a disableHostCheck option to disable this check.

both of which are only true for raw resource requests, but not hot-reloading pushes.

[bebraw]

Closing as this is an intentional behavior as described above.

[ntucker]

@bebraw If you're referring to 1.10.2 of webpack-dev-middleware, that describes removing '*' and does not mention the lack of adding localhost or 127.0.0.1 depending on where the request came from - which is what is done for all requests unrelated to hotreloading.

Please read documented behavior of _this_ project in the 2.4.3 release notes to understand this bug.

"The Host header of the request have to match the listening adress or the host provided in the public option."

[ntucker]

Looking at some of the code, it looks like the 2.4.3 changes did not affect the headers - those were only changed via the middleware bump. However, I would view those changes as incomplete and needing to encompass CORS headers as well.

[shellscape]

I believe this has been resolved by recent changes to host checking. Please call me out if I'm mistaken. Closing this one for now.

[ntucker]

Yes this is fixed now, thanks!