Middleware doesn't redirect and serves 404 when a page doesn't exist

[syahzuan]

Astro info

Astro version            v2.10.14
Package manager          npm
Platform                 linux
Architecture             x64
Adapter                  Couldn't determine.
Integrations             @astrojs/mdx, @astrojs/sitemap

What browser are you using?

Firefox, Chrome

Describe the Bug

This is the same issue in #7752, released in #7851 #7854, but the issue isn't fixed.

I am trying to redirect / (which does not exist) to the localized content (/en or /zh etc), but Astro returns 404 instead of running the middleware.

The bug is reproduced at the link below.

What's the expected result?

Middleware should run before Astro returns 404.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/withastro-astro-stgbcz?file=src%2Fmiddleware.js

Participation

• I am willing to submit a pull request for this issue.

[ematipico]

@syahzuan

I am looking into this. Here's a couple of questions:

• I think it's possible to fix this in development, but there's a high chance this won't work on Cloudflare, because Cloudfare runs first before astro can (even in SSR). Is this the expected result for you?
• Is there a reason why you don't use astro redirects?

[syahzuan]

Here is my use case.
My pages are all localized, placed under a [lang] folder.
To illustrate, example.com/about does not exist, rather it is redirected to its localized content e.g. example.com/en/about or example.com/zh/about, based on the users' accept-language header.
This solution is typically done through middleware.

Now, I could create a [...slug].astro directly under pages folder just to capture url without locale prefix and use Astro.redirect (only redirect logic without content).
But two issues with this solution:

1. While it does the job, I think it's not elegant and seems hacky. Because I am using a page to do what middleware is supposed to do.
2. In my use case, the redirection rules would lead to a large (>100 entries) _routes.json which is not allowed by Cloudflare. I could create my own customized _routes.json as a workaround, but again, it's not an elegant solution.

Let me know if I could provide more info on this.

And really appreciate your quick reply on this @ematipico! Cheers.

[ohansemmanuel]

@syahzuan if you create a default 404.astro page, the middleware will be fired. This is not ideal, but I believe the inconsistency documented in #8244 to likely be the root cause of this.

[ematipico]

I have been talking with @matthewp about this, and we agree that it makes sense for users to have a middleware called when pages don't exist (the default 404 doesn't exist on disk).

However, another discussion was going on where this could cause inconsistencies among adapters.

We might be able to support these cases - as mentioned by @lilnasy - where if an adapter doesn't call our app.render(), the middleware won't be called and cause inconsistencies.

[lilnasy]

Is it possible for you to create an empty index.astro?

The idea is that it will never be used but it will cause the middleware be run.

[lilnasy]

Also, I think there's some nuance to our "default" 404 page — it's not so much a default as it is a backup which is only used in certain cases.

[ematipico]

Myself and @matthewp had a chat about it.

We agreed that this is not a bug because Astro behaves by design: render matched routes (URL route must match the route on disk).

We think this is a feature because it will enhance Astro's behaviour by allowing it to attempt to render routes that aren't matched. This is a new use case that we hadn't considered, and it's worth implementing.

Implementing this feature will have some side effects in serverless environments if the user uses functionPerRoute. In serverless environments, we use the routing system of the hosting platform to say: "this route has to run this handler", so we can't run the middleware beforehand. Maybe users can compensate this shortcoming by using edge middleware, but I don't know how edge functions behave in the different hosting platforms.

We will work on implementing this new feature after 3.0 release.

[ematipico]

I am going ahead and close the issue. This is a feature, and it requires some internal changes, which should also be reflected in the respective adapters.

One of our maintainers - @lilnasy - created a proposal that would solve this issue: withastro/roadmap#681

If you need it, please upvote it!