Issue when using disableDotRule of historyFallback

[sibelius]

• Webpack Version: 4.25.1
• Operating System (or Browser): MacOS
• Node Version: 10.15.0
• webpack-plugin-serve Version: 0.5.0 and 0.8.0

How Do We Reproduce?

You can run yarn start:web on this pull requests entria/entria-fullstack#76

Expected Behavior

• it should render web app
• it should accept . on http url

Actual Behavior

• it does not render anything
  it gives us Uncaught SyntaxError: Unexpected token <

here is the logs from historyApiFallback

Rewriting GET / to /index.html
Rewriting GET /bundle.js to /index.html
Rewriting GET / to /index.html
Rewriting GET /bundle.js to /index.html

I think the problem is that bundle.js is not treated differently

[sibelius]

workaround for now:

historyFallback: {
        disableDotRule: true,
        verbose: true,
        rewrites: [
          {
            from: '/wps',
            to: (context) => (context.parsedUrl.pathname),
          },
          {
            from: '/bundle.js',
            to: (context) => (context.parsedUrl.pathname),
          },
          {
            from: '/sw.js',
            to: (context) => (context.parsedUrl.pathname),
          },
        ],
      },
      static: [outputPath],
      status: false,
    }),

I think it should not send accept headers for .js files

this config works well on webpack-dev-server

[matheus1lva]

Apparently it is falling in the same problem we were having with /wps, where it has accept headers and connect-history-api-fallback is ignoring it.

[matheus1lva]

similar to #94 , when removing accept headers it works as intended. Now why connect-history-api-fallback is breaking at this... is going to be difficult to know!

Edit:

Apparently related to bripkens/connect-history-api-fallback#60 (comment)

If we remove */* from the accept headers, connect-history-api-fallback does not think everything is html and stops rewriting everything. Removing that from the headers seems to fix it.

[shellscape]

OK so we have to make some more considerations for headers @playma256 ?

[matheus1lva]

Seems that we need @shellscape.
I went on a debug session with @sibelius and also searching on github issues, i found that people were also complaining about a similar problem where other assets with accept header were being redirected to /index as well. During the debug, we removed */* from headers and everything worked as expected, we were having /bundle not being redirected to /index.html.

And as we can see, the creator of connect-history-api-fallback doesn't want to deal with it, because "there has been too many downloads without this problem".

I would bet on removing */* from accept header, or even remove the whole property.

[shellscape]

Adding the following to the serve options might work then:

middleware(app) {
  app.use(async (ctx, next) => {
    const { accept, ...headers } = ctx.request.header;
    ctx.request.header = headers;

    await next();
  });
}

[matheus1lva]

It will!
Should we also handle that on our side by default?

[shellscape]

I'm not so sure that's the right fix, because that removes the accept header from every request. We should think on how to solve this without interfering with others who might be looking for that header.

[sibelius]

can we just remove the headers for non .html files?

or should we have this as a new param?

[shellscape]

What if we supported a ! for the headers option that would remove a header from the response? Similar to how globs work.

[matheus1lva]

I guess that would work fine but, wouldn't that insert a new layer if complexity for the user? This would need to be 100% documented, the problem and what the user would have to do.

[sibelius]

using this

middleware(app) {
  app.use(async (ctx, next) => {
    const { accept, ...headers } = ctx.request.header;
    ctx.request.header = headers;

    await next();
  });
}

does not work well

it won't rewrite anything

Not rewriting GET /sw.js because the client did not send an HTTP accept header.
Not rewriting GET /home because the client did not send an HTTP accept header.

[shellscape]

@sibelius what about filtering out the */* header from paths that terminate with .html in the same kind of handler? e.g. something like:

middleware(app) {
  app.use(async (ctx, next) => {
    if (/\.html$/.test(ctx.path)) {
      let { accept } = ctx.request.header;
      accept = accept.replace(/\*\/\*/, '');
      ctx.request.header.accept= accept;
    }
    await next();
  });
}

[sibelius]

My current config to fix historyFallback is like this:

historyFallback: {
        disableDotRule: true,
        verbose: true,
        rewrites: [
          {
            from: '/wps',
            to: context => context.parsedUrl.pathname,
          },
          {
            from: /.js/,
            to: context => context.parsedUrl.pathname,
          },
        ],
      },

[shellscape]

@sibelius but can you test the possible solution above?

[sibelius]

using the middleware above I've got

Uncaught SyntaxError: Unexpected token <

in all pages

this is the bug:

Rewriting GET /bundle.js to /index.html

it should not rewrite .js files

[shellscape]

So much time passes between each comment that I lose track of the context.

What's your proposed solution to fix this?

If this isn't something immediately fixable in WPS, I think we should defer to bripkens/connect-history-api-fallback#60 (comment). The maintainer has agreed to a feature/option to alter the default behavior and has requested an example be added to the repo to show the problem and the new option being used.

Until that gets added, and if there is no immediate fix we can make here to satisfy all needs, I say we add your local fix to the FAQ and close this issue.

[sibelius]

Let’s keep it there

[shellscape]

OK cool. I'll add this to the FAQ in the mean time.

[soulofmischief]

@shellscape is there any negative consequence to using

historyFallback: {
    disableDotRule: true,
    verbose: true,
    rewrites: [
      {
        from: '/wps',
        to: context => context.parsedUrl.pathname,
      },
      {
        from: /\.(?!html)/,
        to: context => context.parsedUrl.pathname,
      },
    ],
  },

instead?

It works at first glance and catches other filetype errors, however I won't be testing it much further because I was giving webpack-plugin-serve a spin since webpack-dev-server is having an issue with proxying over LAN, I cannot get hot module replacement to work with this plugin, or live reloading, and reloading the page takes upwards of 10 seconds.

[shellscape]

I wouldn't know of any negative consequences. You might want to ask with the connect-history-api-fallback folks. But it sounds your app there has bigger issues if all of that is true.