Header propagation is commonly implemented using distributed tracing libraries. Signadot Workspaces supports the following header formats in HTTP 1/2 and gRPC and the corresponding tracing libraries.
There are two mechanisms of propagation that are supported from the OpenTelemetry specification: baggage and tracestate. In both of these cases, a key named
sd-workspace is used to persist information pertaining to Workspaces.
If you're making use of OpenTelemetry instrumentation in your services,
tracestate headers are propagated automatically.
A header named
uberctx-sd-workspace is expected to be propagated by your services. If you're making use of Jaeger instrumentation in your services, headers in this format are propagated automatically.
A header named
ot-baggage-sd-workspace is expected to be propagated by your services. If you're using Datadog's Go language instrumentation libraries, headers in this format are propagated automatically. Support in other languages depends on the library being used and the mode in which it's used.
If you are not using the above libraries, we recommend that you make use of the
baggage header as described in the W3C Baggage Specification. Services would need to propagate this header from each incoming request to any outgoing requests the original handler makes.
The headers that will be set on the entry-point service when using a Signadot preview URL will be in the following format and the application must propagate this header as-is (or with modifications according to the W3C spec) to other services in the system.
Updated about 1 month ago