Dots in URL lead to 404 (regression?)

[Deckluhm]

⚠️ IMPORTANT ⚠️ Please do not ignore this template. If you do, your issue will be closed immediately.

• Read the docs.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• This is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

Describe the bug

URLs with dots are leading to a 404 error instead of correctly displaying the corresponding page.

Note that it works fine with a project created with Vue CLI but it doesn't work with a project created with @vite/create-app (both using Vue 3 with Vue Router 4).

I guess this is a regression from #130 but many things have change with Vite 2 (especially project structure) so it's hard for me to identify why the bug reappeared (but with some guidance I'm happy to help).

Reproduction

• 🔴 Repro created with @vite/create-app (not working): https://github.com/Deckluhm/vite-dots-url-bug
• 🟢 Repro created with Vue CLI (working): https://github.com/Deckluhm/vue-cli-dots-url-bug

Run projects and go to http://localhost:3000/just.a.test (or a similar URL).

System Info

• vite version: 2.0.1 (with @vitejs/plugin-vue 1.1.4)
• Operating System: Ubuntu 20.10
• Node version: 15.10.0
• Package manager (npm/yarn/pnpm) and version: Yarn 1.22.10

[tdxius]

I'm experiencing the same issue when using vite version 2.0.5.

[patak-dev]

There was an issue created about this already here: #2245
But it was closed because of the use of a workaround with a plugin, that may also help you while this is open.
Maybe there is a limitation I'm not aware of, but this looks like a bug, and the other issue was wrongly closed.

[tdxius]

Thank you @matias-capeletto. I can confirm that it works with the plugin.

[TLIQ]

Hi! Did anyone solve problem with serving vite app with dots in several parts like

http://localhost:3000/j.smith/d.porter
I have a combined url with dots, in case of
http://localhost:3000/j.smith
vite-plugin-rewrite-all works great but when I have another one
http://localhost:3000/j.smith/d.porter
I still have a 404 not found

[kleinfreund]

@TLIQ In short, the workaround provided via the Vite plugin https://www.npmjs.com/package/vite-plugin-rewrite-all seems to work for people.

[silverwind]

The behaviour seems to be because vite assumes that if the final segment of the path contains ., the user meant to navigate to a file. This is a pretty bad assumption to take because files without . are valid too (although, uncommon) and modern SPAs generally expect all paths except static assets to be routed to index.html so client-side routing can take effect.

One solution could be to check existance in the file system, and if the file is not there, serve index.html, similar to try_files is often configured in nginx to serve prod apps. With such an mechanism, no option like #2634 is necessary as it'll work correctly in all cases, but it will involve one additional stat call on each request.

[uxsoft]

Hi, I have the same problem. In my case, it's PocketBase adding a JWT token to the URL which I have no control over.

[hbshvn]

Hi, I have the same problem. In my case, it's PocketBase adding a JWT token to the URL which I have no control over.

Same problem using URL with JWT

[nicholasdgoodman]

Hey everyone, ran into the same issue today. If you want a workaround that doesn't involve installing random "fix things" packages such as vite-plugin-rewrite-all, here is a simple middleware function you can add that works for me:

import fs from 'fs';

const dotPathFixPlugin = () => ({
  name: 'dot-path-fix-plugin',
  configureServer: (server) => {
    server.middlewares.use((req,_,next) => {
      const reqPath = req.url.split('?', 2)[0];
      if(!req.url.startsWith('/@') && !fs.existsSync(`.${reqPath}`)) {
          req.url = '/';
      }
      next();
    });
  }
});

Which just checks if the request is a path for an existing file (or special dev server path), and if not just rewrites it to /.

In your vite.config.js file you simply use it:

export default defineConfig({
  plugins: [
    // your other plugins
    dotPathFixPlugin()
  ],
  // rest of the stuff
}

And sure, there are "performance" implications to checking if a file exists, but as long as we are just talking a development server, I cannot see how this is a practical concern. I have to admit I never understood the modern obsession with ultra-fast / hmr, etc. when it means we have to sacrifice application design in favor of a good developer experience.

Edit

I should clarify I am working on a Solid.JS (SPA) application and only currently doing no SSR or SSG. Just in early development mode running a classic SPA.

[silverwind]

Hey everyone, ran into the same issue today. If you want a workaround that doesn't involve installing random "fix things" packages such as vite-plugin-rewrite-all, here is a simple middleware function you can add that works for me:

Interesting solution. Can you clarify what the /@ check is for? Is that some vite-internal routing prefix?

And sure, there are "performance" implications to checking if a file exists

It is possible to cache the stat calls to a certain degree, modules like sirv do just that to serve static files. Thought I generally think stat calls are fast enough generally to not be an hindrance.

[theoephraim]

to follow up on @nicholasdgoodman's solution (thanks!), depending on the rest of our setup, you may need to add a few extra checks, for example:

const dotPathFixPlugin = () => ({
  name: "dot-path-fix-plugin",
  configureServer: (server) => {
    server.middlewares.use((req, _, next) => {
      const reqPath = req.url.split("?", 2)[0];
      if (
        !req.url.startsWith("/@") && // virtual files provided by vite plugins
        !req.url.startsWith("/api/") && // api proxy, configured below
        !existsSync(`./public${reqPath}`) && // files served directly from public folder
        !existsSync(`.${reqPath}`) // actual files
      ) {
        req.url = "/";
      }
      next();
    });
  },
});

[graue]

Thanks Nicholas for the suggested fix!

This was really hard to find because being new to Vite, I didn't realize the dot in the URL was the issue. I just thought every path served from the dev server needed to correspond to a file, so I was looking for some sort of "how to do client-side routing with Vite" guide, to tell me how to define dynamic paths...

[posva]

Given that . are valid characters and URLs and that https://www.npmjs.com/package/vite-plugin-rewrite-all has now almost 30k downloads weekly (plus people using a raw plugin in their vite config). I think it would be great not to leave this hanging too much longer. The longer is stays open, the longer people keep finding workarounds and not use dots in their paths, despite being totally valid.

It's worth noting that the plugin workaround breaks other features like opening files with vitest

[Minho-Lee]

This took me a fair amount of to debug, and ended up resolving the issue with the above package mentioned (https://www.npmjs.com/package/vite-plugin-rewrite-all). Would love to see this resolved so we don't have to rely on external packages/plugins and continue using valid urls with ..

[eteeselink]

Thanks sapphi-red and patak-dev! This fixes the problem for me when switching to 5.0.0-beta.0

[mahnunchik]

I've faced the same issue on vite/4.4.9. When the release date of 5.0.0 ?

• In History Mode, a route containing a symbol . will be lost after refreshing #4344
• Browser return 404 when path includes .(dot) #5632
• spa-fallback is ignore if the path has dot #2190

[redmundas]

having this issue with [email protected]

[bluwy]

It's not fixed in Vite 4 as it's a breaking change. You can start using the Vite 5 beta to fix it. Vite 5 stable will come around mid October.

[KaKi87]

it's a breaking change

How so ?