Skip to content
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

behavior of static and historyApiFallback #2716

Open
knagaitsev opened this issue Aug 20, 2020 · 5 comments
Open

behavior of static and historyApiFallback #2716

knagaitsev opened this issue Aug 20, 2020 · 5 comments

Comments

@knagaitsev
Copy link
Collaborator

Expected Behavior

Static serving middleware for the dev server should only need to be applied to the express server once via this.app.use(...)

Actual Behavior

static middleware is applied to the express server multiple times in order to make historyApiFallback work as expected. This is explained here: #2670 (comment)

A similar thing seems to have been added for the middleware feature as seen here, as it is added multiple times:

runnableFeatures.push('setup', 'before', 'headers', 'middleware');
if (this.options.proxy) {
runnableFeatures.push('proxy', 'middleware');
}
if (this.options.contentBase !== false) {
runnableFeatures.push('contentBaseFiles');
}
if (this.options.historyApiFallback) {
runnableFeatures.push('historyApiFallback', 'middleware');

Solution

We need to find a way to either apply all of this middleware once without having any breaking changes, or have intentional slight breaking changes while only applying the middleware once. We should also look into if applying the same middleware many times causes performance losses, or if it is an acceptable thing to do.

@csr632
Copy link

csr632 commented Feb 1, 2021

Yes, if the proxy feature or the historyApiFallback feature is enabled, http-proxy-middleware will be applied to the express server multiple times.

@alexander-akait
Copy link
Member

alexander-akait commented Sep 13, 2021

historyApiFallback also break HEAD request in some cases, we need fix it, more information here webpack/webpack-dev-middleware#749

@alexander-akait
Copy link
Member

Partially fixed #4501

@BRMatt
Copy link

BRMatt commented Sep 28, 2022

I ran into this issue earlier and spent a few hours trying to debug it. In my case it turned out that configuring the webpack-dev-server proxy option with context and router options, but not target causes webpack-dev-server to ignore the context option when configuring the proxy:

const getProxyMiddleware = (proxyConfig) => {
// It is possible to use the `bypass` method without a `target` or `router`.
// However, the proxy middleware has no use in this case, and will fail to instantiate.
if (proxyConfig.target) {
const context = proxyConfig.context || proxyConfig.path;
return createProxyMiddleware(
/** @type {string} */ (context),
proxyConfig
);
}
if (proxyConfig.router) {
return createProxyMiddleware(proxyConfig);
}
};

My understanding is that if you're using router you don't need to specify target, but if I don't then webpack-dev-server configures the proxy to intercept every request, rather than just the requests that match the context.

In my case I'm only proxying a single endpoint, so I've configured context and target to the same value, and let the router reconfigure the target on each request. This appears to fix the conflict with historyApiFallback.

@alexander-akait
Copy link
Member

I think we can improve/fix:

return createProxyMiddleware(proxyConfig); 

So we will always pass options even you don't have router, what do you think?

Swapnilden added a commit to Swapnilden/webpack-dev-server that referenced this issue Apr 11, 2024
This commit refactors the middleware application logic in the webpack-dev-server codebase to ensure that middleware is applied only once, regardless of how many times it's called. 

Previously, certain middleware, such as static serving middleware, was being applied multiple times to support features like `historyApiFallback`. This refactor eliminates duplicate middleware application by introducing a mechanism to track applied middleware and applying each middleware only once.

Changes:
- Introduced `appliedMiddleware` array to track applied middleware.
- Created `applyMiddlewareOnce` function to apply middleware only if it hasn't been applied before.
- Updated webpack-dev-server codebase to utilize `applyMiddlewareOnce` for applying middleware associated with various features.

This update aims to improve code efficiency and prevent unintended behavior or performance issues caused by duplicate middleware application.

Fixes: webpack#2716
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants