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.

Sign up for GitHub

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

Jump to bottom

behavior of static and historyApiFallback #2716

Open
knagaitsev opened this issue Aug 20, 2020 · 5 comments · May be fixed by #5149
Open

behavior of static and historyApiFallback #2716

knagaitsev opened this issue Aug 20, 2020 · 5 comments · May be fixed by #5149
Labels
scope: server semver: patch severity: 5 (confusing) type: feature type: refactor

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:

webpack-dev-server/lib/Server.js

Lines 548 to 559 in 4ab1f21

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 alexander-akait mentioned this issue Sep 13, 2021
Closed
@alexander-akait
Copy link
Member

alexander-akait commented Sep 13, 2021 •
edited

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

awwit added a commit to awwit/webpack-dev-server that referenced this issue Jun 27, 2022
@awwit
chore: bump connect-history-api-fallback from 1.6.0 to 2.0.0 (webpack…
f20d131 
…#2716)
@awwit awwit mentioned this issue Jun 27, 2022
Merged
6 tasks
@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:

webpack-dev-server/lib/Server.js

Lines 2174 to 2189 in 49efdf8

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
@Swapnilden
Refactor webpack-dev-server middleware application logic
a39fb68 
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
@Swapnilden Swapnilden linked a pull request Apr 11, 2024 that will close this issue
Open
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
scope: server semver: patch severity: 5 (confusing) type: feature type: refactor
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Refactor webpack-dev-server middleware application logic Swapnilden/webpack-dev-server
4 participants
@BRMatt @alexander-akait @csr632 @knagaitsev