-
-
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
feat: middleware and virtual routes #10206
feat: middleware and virtual routes #10206
Conversation
🦋 Changeset detectedLatest commit: a86386b The changes in this PR will be included in the next version bump. 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 |
9bce54c
to
9f77710
Compare
it('does not return custom headers for invalid URLs', async () => { | ||
it('returns custom headers in the default 404 response', async () => { | ||
const result = await fixture.fetch('/bad-url'); | ||
assert.equal(result.status, 404); | ||
assert.equal(Object.fromEntries(result.headers).hasOwnProperty('x-astro'), false); | ||
assert.equal(Object.fromEntries(result.headers).hasOwnProperty('x-astro'), true); | ||
}); |
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.
The test checks that configured headers added in config.server.headers
are NOT added in the 404 responses.
This behavior was limited to astro's default 404 page - if the user added a custom 404.astro
, server.headers
are still added.
The new behavior is that server.headers
apply to all astro-generated responses - the distinction between astro's default 404 page and user's 404.astro
is gone.
lgtm, still in draft though and missing a changeset. |
Manually adding |
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.
Just setting a block for @lilnasy ! (I'm sure docs will want to look at this anyway) 💜
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.
blocking per request
.changeset/brown-pets-clean.md
Outdated
|
||
The astro middleware now runs when a matching page or endpoint is not found. Previously, a `pages/404.astro` or `pages/[...catch-all].astro` route had to match to allow middleware. This is now not necessary. | ||
|
||
Note that some adapters may need to update to let Astro's SSR code handle the not-found case. |
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.
nit: "to update.." what? It feels like we should hint at something or maybe rephrase the sentence.
It would be great if the changelog actually explains what an adapter maintainer should update in order to "fix" this.
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.
I feel it adequately explains the change necessary.
Adapters may look at the list of routes given by astro to create their platform-specific routing file. And the platform may then run SSR code only for routes known to be on-demand rendered. The website would then fallback to a platform-designed 404 page. SST, vercel and cloudflare (in one routing strategy) work like this.
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.
I feel it adequately explains the change necessary.
I am sure it is, from your point of view. However, I fear that we don't provide enough explanation to people who have less context and knowledge than you. If you think this phrase is more than enough, we should remove it.
Adapters may look at the list of routes given by astro to create their platform-specific routing file. And the platform may then run SSR code only for routes known to be on-demand rendered. The website would then fallback to a platform-designed 404 page. SST, vercel and cloudflare (in one routing strategy) work like this.
You just replied with something that we can add to the changeset 😅
@lilnasy What about the documentation? The template is empty. We should have a PR for that, right? |
Not necessarily. We don't explicitly document that middleware won't run in this case. We should also hold explicitly saying that will , until we know it works this way across adapters. |
Sorry for being pedantic, but I am a bit concerned by this kind of approach:
And how do we plan to do that? The PR doesn't say anything about it. |
updated the description |
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.
Thank you, Arsh, for addressing my concerns! Another minor
ready for the next release. Let's wait for docs :)
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.
Tiny suggestion from docs!
We should update the documentation: https://docs.astro.build/en/guides/middleware/ We need to mention that now the middleware will run on 404 pages |
Co-authored-by: Sarah Rainsberger <[email protected]>
8b3378a
to
a86386b
Compare
Changes
404
page #8244Testing
Docs
Mentions of
404.astro
or spread routes needing to exist to run middleware should be removed.