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.

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

trailingSlash redirect does not preserve search params for prerendered routes #11138

Closed
matindow opened this issue Nov 29, 2023 · 2 comments · Fixed by #11142
Closed

trailingSlash redirect does not preserve search params for prerendered routes #11138

matindow opened this issue Nov 29, 2023 · 2 comments · Fixed by #11142

Comments

@matindow
Copy link

matindow commented Nov 29, 2023

Describe the bug

using adapter-cloudflare-workers since @sveltejs/adapter-cloudflare-workers@1.2.1 it now properly redirects trailing slash urls to remove the trailing slash. however, if the page is prerendered, any search params are not preserved in the redirect:

  • example.com/page/?search=params automatically 308 redirects to example.com/page

expected behavior (also local dev behavior):

  • example.com/page/?search=params should instead automatically 308 redirect to example.com/page?search=params

quick testing shows adapter-cloudflare and adapter-node behaving the same way, stripping out the query params.

the specifics of how search params are intended to be handled in this case are not mentioned in the docs, so i don't know if this is explicitly a bug, but it seems to me to be at the very least inconsistent.
(it created a confusing headache for us when a site began inexplicably losing ad tracking information over the past two weeks due to the update and some legacy ads having made use of trailing slash urls.)

this should be pretty easy to recreate in any project, but i put together a minimal example from a slightly modified version of the sveltekit skeleton app.

Reproduction

https://github.com/matindow/sveltekit-cloudflare-workers-example

Logs

No response

System Info

System:
  OS: macOS 14.1.1
  CPU: (8) arm64 Apple M2
  Memory: 490.45 MB / 24.00 GB
  Shell: 5.9 - /bin/zsh
Binaries:
  Node: 20.3.1 - ~/.nvm/versions/node/v20.3.1/bin/node
  npm: 9.8.0 - ~/.nvm/versions/node/v20.3.1/bin/npm
  pnpm: 8.6.8 - ~/.nvm/versions/node/v20.3.1/bin/pnpm
Browsers:
  Chrome: 119.0.6045.159
  Edge: 119.0.2151.72
  Safari: 17.1
npmPackages:
  @sveltejs/adapter-auto: ^2.0.0 => 2.1.1 
  @sveltejs/adapter-cloudflare-workers: ^1.2.1 => 1.2.1 
  @sveltejs/kit: ^1.27.4 => 1.27.6 
  svelte: ^4.2.7 => 4.2.7 
  vite: ^4.4.2 => 4.5.0

Severity

annoyance

Additional Information

No response

@eltigerchino
Copy link
Member

eltigerchino commented Nov 29, 2023

Looking at the code it’s definitely a mistake on my part for leaving the search param out in the cloudflare adapters. However, the node adapter has this conditional so that’s weird it doesn’t re-add the search params.

if (query) location += search;

Also curiously, the sveltekit cloudflare pages deployment still redirects with search params intact https://cloudflare.demo.svelte.dev/about/?abc=1

I’ll have to get on a laptop and run the repro.

@matindow
Copy link
Author

matindow commented Nov 29, 2023

Looking at the code it’s definitely a mistake on my part for leaving the search param out in the cloudflare adapters. However, the node adapter has this conditional so that’s weird it doesn’t re-add the search params.

if (query) location += search;

Also curiously, the sveltekit cloudflare pages deployment still redirects with search params intact https://cloudflare.demo.svelte.dev/about/?abc=1

I’ll have to get on a laptop and run the repro.

apologies, my earlier quick adapter-node test was just running vite preview, which i assumed would hit the same logic as the build, but i just checked it again after actually building and serving from node and the redirect preserves the search params as expected/correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants