-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Dropped requests when run through reverse proxy #1418
Comments
The very same problem. I've updated Versions:
Options we use:
There are a lot |
My hacky workaround: edit/fork const dynamicSocksPort = true;
if (!urlParts.port || urlParts.port === '0' || dynamicSocksPort) { Would be great if that would be some dev-server parameter! The |
OP here. For my dev environment I ended up dropping my NGINX reverse proxy altogether and use the reverse proxying feature of the webpack dev server instead. Obviously this solves the problem of dropped requests, but it's still a sub-optimal solution as this is now yet another point at which my dev environment is going to differ from production. |
Still a problem today. Having this issue in a dev environment where we have 2 frontend Quasar apps (Admin & Client) & API wanting them to be on subfolders behind a reverse proxy (Traefik & docker) maybe I should just ditch subfolders for the frontends and use subdomains? SockPath should be /admin/socket or /client/socket for example. Even with subdomains, I still have the issue of it putting the Port Number in. Going to try patching the package similar to @wtho with patch-package. Add to package.json
Install patch-package via npm or yarn, can use save-dev npm yarn Apply the change from wtho Edit: const dynamicSocksPort = true;
if (!urlParts.port || urlParts.port === '0' || dynamicSocksPort) { Generate the patch and optionally commit the patch to your projects git. Note: If running this in your docker container without git installed you will get an error when it trys to compare the clean code. This generates a diff patch in patches/webpack-dev-server+3.1.14.patch Feature Request: |
For webpack-dev-server v4 you can specify |
It's for webpack 5, not 4 |
Code
https://github.com/kasvtv/webapck-dev-server-issue
Expected Behavior
When behind a reverse proxy, devServer reliably serves files and the
sockjs-node
requests are sent through either the host + protocol of the devServer itsself or through the host + protocol of the reverse proxyActual Behavior
First of all, great plugin, HMR makes my days at the office so convenient and I can imagine many others'. DevServer has a little weird behaviour behind a reverse proxy though. It randomly drops requests when accessed through a reverse proxy! Especially when a handful of medium-sized files are transferred, this issue shows itself more often, but in the small example it does happen with at least 25% of all page loads for me. When the request finally times out (10s in the example), it seems to reattempt and it does work.
Furthermore, the
sockjs-node
calls are sent through the protocol that the proxy uses (HTTPS) instead of the devServer itsself (HTTP), which wouldn't be a problem, if it weren't that they go to the port number of the devServer and not of the remote proxy through which I visit the page with my browser.Before and after:
![webpack dev server issue](https://user-images.githubusercontent.com/1628729/40808677-36884d86-6528-11e8-93eb-c0fa5a1b8f58.png)
For Bugs; How can we reproduce the behavior?
Clone my repository. Set up NGINX with included config file. Hit
npm i
npm run dev
. Open localhost through Chrome 67. I have to say that it happens on a multitude of browsers, module versions and NGINX versions.For Features; What is the motivation and/or use-case for the feature?
I'm a front-end dev and I run a local development instance that needs to connect to a remote staging back-end. Because of our fragmented microservice architecture and strict resource sharing policies, I must use a reverse proxy that routes requests from
https://localhost/api
tohttps://stage.domain.com/api
with the same rules as the remote would do internally. Currently, this gives me the above problems and is hard to work with. It does eventually load after the timout finishes, but this slows me down in my work since I can't set the timeout too low.The text was updated successfully, but these errors were encountered: