-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Fix Vite client route requests with pre-processed search params #8740
Conversation
🦋 Changeset detectedLatest commit: a45f60b The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR!
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Issue if you have middleware that pass query string through any processing. anything WHATWG compatible will render a query param without a value ending with
=
this breaks matching in the vite plugin.Included code so that vite plugin will match against the supported query string if it ends in '='.
another solution would just change the query string to something a bit more compatible like
?client-route=1
Would be willing to open a PR for that. I went for this one due to it being compatible with current solution.Testing Strategy:
Tested on a custom express server that had a searchParams filter that parses the query string that transforms
?client-route
into?client-route=
because of how WhatWG URL serializes searchParams.the middleware mock basically looks like this (with 'http-hook' package installed):
see stackblitz: https://stackblitz.com/edit/remix-run-remix-xzvnld?file=server.ts
Came across this because I have some security hooks/middleware that process the query string.