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

> At the moment there are no plans to implement baggage as part of the user-agent. It will typically be done in the JavaScript library executing on the page. This JavaScript library will need to be configured to account for cors correctly.

I'm having a bit of difficulty reconciling this with the description in the [explainer](https://github.com/w3c/distributed-tracing-wg/blob/main/EXPLAINER.md): _"We also propose a response header which can be used to report a trace ID back to the caller to ... correlate the initial page load of a browser and all subsequent requests to a server side trace"_ and _"The browser uses this information to provide a trace ID for all subsequent requests within this one load cycle"_.

From your explanation above I understand that the user's browser would simply ignore the header and the responsibility of propagating the baggage value would be on the client-side JS executing on a given page. This brings up a few thoughts:
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?
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.
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.


-- 
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-932228741