feat(astro): Add distributed tracing via <meta> tags

[Lms24]

This PR adds <meta> tag injection in our new handleRequest Astro middleware to enable distributed traces between BE and FE transactions.

This is also the first step towards exporting a <meta> tag helper function (tracked in #8438). In a future PR I'll extract the function to the core or utils package and export it in our server-side SDKs.

As with all our connected traces via tags, the trace ordering is wrong in the sense that the FE transaction is the child of the BE transaction. We should fix this but this is out of scope for this PR

ref #9444
ref #8438

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped)	65.25 KB (0%)
@sentry/browser (incl. Tracing, Replay) - Webpack with treeshaking flags (gzipped)	55.49 KB (0%)
@sentry/browser (incl. Tracing) - Webpack (gzipped)	30.98 KB (0%)
@sentry/browser - Webpack (gzipped)	21.3 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped)	61.83 KB (0%)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped)	29.1 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped)	21.24 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed)	194.91 KB (0%)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed)	88.32 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed)	63.3 KB (0%)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped)	31.81 KB (0%)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped)	65.61 KB (0%)
@sentry/react - Webpack (gzipped)	21.34 KB (0%)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped)	82.35 KB (0%)
@sentry/nextjs Client - Webpack (gzipped)	48.13 KB (0%)
@sentry-internal/feedback - Webpack (gzipped)	15.98 KB (0%)

[lforst]

m: Honestly I am a little worried here for multiple reasons:

• I don't understand the Request/Response APIs enough yet but my worry is that this will consume the repsonse stream and somehow make it unavailable for anything that tries to access it.
• I believe with our approach here we will definitely prevent streamed responses from being streamed and just completely block right? This could hurt TTFB.
• I don't know how to feel about the heuristic to find the head tag here 😂. Using an HTML parser to properly find it is probably overkill?
• Let's make absolutely sure this doesn't open any XSS vectors. Maybe we run it through a regexp before writing to the HTML.

[Lms24]

I don't understand the Request/Response APIs enough yet but my worry is that this will consume the repsonse stream and somehow make it unavailable for anything that tries to access it.
I believe with our approach here we will definitely prevent streamed responses from being streamed and just completely block right? This could hurt TTFB.

It's a good point. Astro uses streaming but they also show a similar example for modifying HTML in their middleware docs. I'm gonna ask the Astro folks if there are performance concerns with doing this.

I don't know how to feel about the heuristic to find the head tag here 😂. Using an HTML parser to properly find it is probably overkill?

Agreed, it's super basic but we use the identical approach in SvelteKit and so far it worked decently well. Using a parser is for sure a performance concern. My pragmatic take would be to go with this and improve the lookup logic once we discover problems here.

Let's make absolutely sure this doesn't open any XSS vectors.

Generally, I agree but I'm not entirely sure about the XSS vector. I guess for something malicious to end up in here, the SDK's options (release, environment) or the transaction data (name, ids) would need to be somehow modified beforehand. Do you see any obvious ways how this could happen?

Maybe we run it through a regexp before writing to the HTML.

I think this would work decently well for sentry-trace content but baggage is a little more arbitrary. Lemme try to come up with something.

[lforst]

Astro uses streaming but they also show a similar example for modifying HTML

Alright if Astro is recommending this it's probably fine.

My pragmatic take would be to go with this and improve the lookup logic once we discover problems here.

Sounds good to me.

Do you see any obvious ways how this could happen?

No obvious ways, but if we can come up with a simple way to ensure the string cant be escaped it would be great.

[Lms24]

@lforst I added a baggage regex check in 272cbbd

for sentry-trace, we already had a regex

We'll only serialize the baggage/sentry-trace content if the regexes match.

[Lms24]

this is technically incorrect because ";" is valid if baggage values have properties but afaik we don't support this when parsing so we should be good 🤞 (properly matching properties blows up the complexity of the regex quite a bit)

[lforst]

Awesome! Thank you!