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

Handle static routes in SSR-configured Astro applications #13116

Closed
Lms24 opened this issue Jul 30, 2024 · 2 comments · Fixed by #13306
Closed

Handle static routes in SSR-configured Astro applications #13116

Lms24 opened this issue Jul 30, 2024 · 2 comments · Fixed by #13306
Labels
Package: astro Issues related to the Sentry Astro SDK

Comments

@Lms24
Copy link
Member

Lms24 commented Jul 30, 2024

Description

This came up internally in Slack. There are cases where users configure their Astro app as server (i.e. SSR) but explicitly set some pages as static pages (i.e. opt out of SSR). Our Astro middleware is injected if we find a server-configuration.

Now in case of requests being made to static pages, our middleware accesses properties in the middleware context that should only be accessed in SSR routes. As a result, the server logs warnings:

`Astro.request.headers` is unavailable in "static" output mode, and in perendered pages within "hybrid" and "server" output modes.

We need to somehow find a flag to check in the middleware if the route we’re accessing is static vs. SSR. And if static, we bail and don’t touch the headers

@Lms24 Lms24 added the Package: astro Issues related to the Sentry Astro SDK label Jul 30, 2024
@pawelgrzybek
Copy link

Hi, I encountered this issue as well. No matter if the output config is server or hybrid, when it encounters a statically rendered page, it logs…

`Astro.request.headers` is unavailable in "static" output mode, and in prerendered pages within "hybrid" and "server" output modes. If you need access to request headers, make sure that `output` is configured as either `"server"` or `output: "hybrid"` in your config file, and that the page accessing the headers is rendered on-demand.

It is especially annoying in case when the page is mostly static, with a very few exceptions of server side rendered output (hybrid mode).

@Lms24
Copy link
Member Author

Lms24 commented Aug 12, 2024

yeah, we currently treat hybrid and server in the same way. I'll put this on my todo list for this week but can't make promises because we're pretty much depending on what Astro gives us to differentiate the configuration on a route level.

Lms24 added a commit that referenced this issue Aug 12, 2024
#13306)

In Astro middleware, we're not allowed to access the `request.headers`
object if the incoming request is for a statically generated/prerendered
route. Since we accessed these headers previously, users would get a
warning as reported multiple times and tracked in
#13116.
This patch fixes that by checking for static vs dynamic route
Lms24 added a commit that referenced this issue Aug 12, 2024
builds on top of #13306, found while working on #13116

This PR ensures that we correctly extract the request data in our Astro
middleware. Previously we didn't convert the `request.headers` object
into a `Record<string, string>` but simply passed a `Headers` instance.
This caused problems with the `requestDataIntegration` which doesn't
handle the instance correctly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Package: astro Issues related to the Sentry Astro SDK
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants