fix: prevent dev server crashing on malformed URI (fix #6300)

[toSayNothing]

Description

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

---

when there is URIError, the dev server will crash because it didn't catch the error
reprodution : open url like http://localhost:3000/a%a

[Niputi]

would it be better to first try with decodeURI and then without?

decodeURI change was introduced in #4728, with other places than this so other places might need to be updated too

[bluwy]

I think that makes sense too. Like some sort of tryDecodeURI utility. The only other place I found which might hit the decode error was viteServeStaticMiddleware, but that middleware is instantiated after viteTransformMiddleware (where this PR fixes), so this PR would indirectly cover viteServeStaticMiddleware too

[toSayNothing]

i just found that there's already a errorMiddleware which can handle the error and prevent crash🤣, whether in transformMiddleware or serveStaticMiddleware, looks like this:

so i correct the return with next(e) , so the error can be passed to the errorMiddleware to handle it:

after passing to errorMiddleware, therefor we don't need to specifically address this type of error in all places.

[Niputi]

@bluwy @patak-dev what do you think is best fallback or showing error message?

[bluwy]

Looking back now, I think showing an error message may be safer, since having a fallback might imply that we support it, which we might not. So using next(e) looks good to me. Neat solution too.

@toSayNothing Re viteServeStaticMiddleware, I'm taking back what I said 😅 viteTransformMiddleware can be skipped, so we need to handle decodeURI for viteServeStaticMiddleware too:

vite/packages/vite/src/node/server/middlewares/static.ts

Line 71 in 8bdb184

const url = decodeURI(req.url!)

[toSayNothing]

@bluwy 🤣i have debugged and found that :
connect can handle the Synchronization function 's error , but not the Asynchronous function .
viteServeStaticMiddleware is sync, so it can handle by the connect itself(call try catch)
but the async viteTransformMiddleware will crash the server if not handly by catch(e){return next(e)}

online connect repo : https://stackblitz.com/edit/node-w8ukhk

[bluwy]

Nice observation @toSayNothing. That's an interesting behaviour from connect. It would sure be nice if it handles promises too, but for now this looks good to me.