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

Dynamic Routes that starts with 404 redirects to 404 page rather than loads properly #11595

Open
1 task done
braden-w opened this issue Aug 2, 2024 · 5 comments · May be fixed by #12182
Open
1 task done

Dynamic Routes that starts with 404 redirects to 404 page rather than loads properly #11595

braden-w opened this issue Aug 2, 2024 · 5 comments · May be fixed by #12182
Assignees
Labels
- P3: minor bug An edge case that only affects very specific usage (priority) feat: routing Related to Astro routing (scope)

Comments

@braden-w
Copy link

braden-w commented Aug 2, 2024

Astro Info

Astro                    v4.12.2
Node                     v22.4.1
System                   macOS (arm64)
Package Manager          pnpm
Output                   hybrid
Adapter                  none
Integrations             @astrojs/react
                         @astrojs/tailwind

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

In dynamic routes, any dynamic route that starts with "404", even if it is not an exact match like "4045", results in a 404 page.

If there is a /pages/todos/[id].astro file, visiting /todos/4045, /todos/404a, etc. gives 404 pages such as the following:

CleanShot 2024-08-01 at 17 37 08

What's the expected result?

If there is a /pages/todos/[id].astro file, visiting /todos/4045, /todos/404a, etc. should instead meet pass "4045" or "404a" as a param and load the corresponding todo.

Link to Minimal Reproducible Example

https://stackblitz.com/github/withastro/astro/tree/latest/examples/basics?file=src%2Fpages%2Findex.astro

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label Aug 2, 2024
@agrofx1
Copy link

agrofx1 commented Aug 6, 2024

So, I examined source code and figured out that problem occurs here or here.

@ematipico
Copy link
Member

I assigned the issue to you @braden-w

We should apply the same fix for 505 pages:

function getCustom500Route(manifestData: ManifestData): RouteData | undefined {
const route500 = /^\/500\/?$/;
return manifestData.routes.find((r) => route500.test(r.route));
}

return url.pathname.startsWith(`${base}/404`) || url.pathname.startsWith(`${base}/500`);

thank you @agrofx1 for the help

@ematipico ematipico added - P3: minor bug An edge case that only affects very specific usage (priority) feat: routing Related to Astro routing (scope) and removed needs triage Issue needs to be triaged labels Aug 12, 2024
@ematipico
Copy link
Member

@braden-w any updates?

@braden-w braden-w linked a pull request Oct 10, 2024 that will close this issue
@braden-w
Copy link
Author

@ematipico Just attempted my first PR at #12182 ! Let me know if it looks good. Thanks for the reminder

@dwighthouse
Copy link

@braden-w Your PR looks good to me after a cursory glance through it.

On a related note, do you happen to know what mechanism within the codebase is responsible for changing the output file paths from /404/index.html and /500/index.html to 404.html and 500.html respectively? That is, where is the specific exception code to treat these pages different from all other pages when deciding where to output the rendered files?

I've been trying to find a way to output these pages the way any other page is output, preferably with a configuration option for people who want their 404 and 500 pages to be at /404/ and /500/, respectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P3: minor bug An edge case that only affects very specific usage (priority) feat: routing Related to Astro routing (scope)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants