[whatwg/fetch] CORS safelisting trace context header (#911)

## Problem statement
[W3C trace context](https://www.w3.org/TR/trace-context/) defines a format to exchange distributed trace context between different software components. Specifically for HTTP protocol, the specification defines the format for two headers, namely \`traceparent\` and \`tracestate\`.

From the trace context [specification](https://www.w3.org/TR/trace-context/#design-overview):

Trace context is split into two individual propagation fields supporting interoperability and vendor-specific extensibility:

*   traceparent describes the position of the incoming request in its trace graph in a portable, fixed-length format.
*   tracestateextends traceparentwith vendor-specific data represented by a set of name/value pairs. Storing information in tracestate is optional.

For example, a client traced in the congo system adds the following headers to an outbound http request:

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

tracestate: congo=t61rcWkgMzE

Web applications use this context propagation mechanism by adding the traceparent and tracestate headers to outbound HTTP requests. There are already implementations from observability providers, including the [Elastic APM Real User Monitoring agent](https://github.com/elastic/apm-agent-rum-js), OpenTelemetry, and Dynatrace’s agents. However, web applications commonly make use of services hosted on different origins than the application itself. It is desirable to include cross-origin HTTP requests in captured traces, meaning that we need to propagate trace context with these requests.

Scenarios where this is necessary:

1.  A developer builds a web application that calls a third party API, and the API is not behaving as expected. They contact the API’s provider and pass along the trace IDs of problematic requests. The third party vendor is able to match these IDs to traces and other telemetry in their systems so that they can more quickly debug the issue.

In order to comply with the Cross Origin Resource Sharing (CORS) protocol browsers need to verify that the server would allow access to the HTTP resource. A concise algorithm, defined by the W3C, is used to determine if the HTTP request requires a preflight (OPTIONS) request which is used to verify the server’s consent for receiving the following HTTP request. One of the criterias for this algorithm is the HTTP headers included in the request. Essentially if one of the request headers is not part of the [CORS-safelisted request headers](https://fetch.spec.whatwg.org/#cors-safelisted-request-header), the preflight request is required. In the case of trace context both \`traceparent\` and \`tracestate\` are not part of the CORS-safelist therefore adding these headers to HTTP requests would necessitate a preflight request, this poses two challenges for observability providers:

1.  The preflight request increases the latency for the original HTTP request since there is an extra roundtrip to verify that the application can access the HTTP resource.
2.  Unless the server (managed by observability user) is modified to respond appropriately to the preflight request, the request would fail. This prevents observability providers from propagating the trace context across cross-origin requests by default, therefore relying on the user to modify each of their services.

## Solution 
I propose to add both \`traceparent\` and \`tracestate\` to the [CORS-safelisted request headers](https://fetch.spec.whatwg.org/#cors-safelisted-request-header). By doing so browsers can avoid the preflight request for these headers and therefore allowing observability providers to add these headers by default to all HTTP requests.

The proposed solution is aligned with the CORS protocol since these headers do not require any state change on the server side and are only meant to exchange the trace information.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/911