Re: [w3ctag/design-reviews] Distributed Tracing WG: Baggage specification (#650)

> 1. How will scripts executing on a page learn the value of the `baggage` header? Are you also proposing a JS API to get this data?

Today we only support ajax calls inside a single page load. We do not propose a JS API for the actual page loads at this point. We were considering using `Server-Timing` header to return some correlation data from the server back to the page, but this is not something we are actively working on.

> 2. This means that the baggage will -- in practice -- be propagated only for a subset of requests made by a given page, and will exclude `no-cors` resource loads. I think this means that the value will only be propagated for programmatic loads using the `fetch()` API if the caller makes sure to add the `baggage` header.

Yes, implementations will be JS Library-specific.

> 3. Pages with some third-party resources that don't opt in via `Access-Control-Allow-Headers` may have a hard time enabling this. My guess is that most pages are in this situation.

Yes, this standard makes situation a little bit better as it defines a unified header when in the past custom headers were typically used. It will be easier to ask `Access-Control-Allow-Headers`  to enable `baggage` than any vendor-specific headers. And we may provide some helper methods for this. We had conversation about including Distributed Tracing Working Group headers to the default set of allowed headers. But I don't think this will be happening short term

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/650#issuecomment-947011961