This specification defines standard HTTP headers and a value format to propagate context information that enables distributed tracing scenarios. The specification standardizes how context information is sent and modified between services. Context information uniquely identifies individual requests in a distributed system and also defines a means to add and propagate provider-specific context information.
Status of This DocumentThis section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This specification includes editorial updates since the 6 February 2020 W3C Recommendation.
This document was published by the Distributed Tracing Working Group as a Recommendation using the Recommendation track.
W3C recommends the wide deployment of this specification as a standard for the Web.
A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations.
This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 2 November 2021 W3C Process Document.
Table of ContentsAs well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
2. Overview 2.1 Problem StatementDistributed tracing is a methodology implemented by tracing tools to follow, analyze and debug a transaction across multiple software components. Typically, a distributed trace traverses more than one component which requires it to be uniquely identifiable across all participating systems. Trace context propagation passes along this unique identification. Today, trace context propagation is implemented individually by each tracing vendor. In multi-vendor environments, this causes interoperability problems, like:
In the past, these problems did not have a significant impact as most applications were monitored by a single tracing vendor and stayed within the boundaries of a single platform provider. Today, an increasing number of applications are highly distributed and leverage multiple middleware services and cloud platforms.
This transformation of modern applications calls for a distributed tracing context propagation standard.
2.2 SolutionThe trace context specification defines a universally agreed-upon format for the exchange of trace context propagation data - referred to as trace context. Trace context solves the problems described above by
A unified approach for propagating trace data improves visibility into the behavior of distributed applications, facilitating problem and performance analysis. The interoperability provided by trace context is a prerequisite to manage modern micro-service based applications.
2.3 Design OverviewTrace 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. Its design focuses on fast parsing. Every tracing tool MUST properly set traceparent
even when it only relies on vendor-specific information in tracestate
tracestate
extends traceparent
with vendor-specific data represented by a set of name/value pairs. Storing information in tracestate
is optional.Tracing tools can provide two levels of compliant behavior interacting with trace context:
traceparent
and tracestate
headers and guarantee traces are not broken. This behavior is also referred to as forwarding a trace.traceparent
header and relevant parts of the tracestate
header containing their proprietary information. This is also referred to as participating in a trace.A tracing tool can choose to change this behavior for each individual request to a component it is monitoring.
4. Processing ModelThis section is non-normative.
This section provides a step-by-step example of a tracing vendor receiving a request with trace context headers, processing the request and then potentially forwarding it. This description can be used as a reference when implementing a trace context-compliant tracing system, middleware (like a proxy or messaging bus), or a cloud service.
4.1 Processing Model for Working with Trace ContextThis processing model describes the behavior of a vendor that modifies and forwards trace context headers. How the model works depends on whether or not a traceparent
header is received.
If no traceparent header is received:
traceparent
and a tracestate
header.traceparent
header is not received, the vendor creates a new trace-id
and parent-id
that represents the current request.tracestate
header is received without an accompanying traceparent
header, it is invalid and MUST be discarded.tracestate
header and add a new key/value pair.traceparent
and tracestate
header for the outgoing request.If a traceparent
header is received:
traceparent
and a tracestate
header.traceparent
header is present, the vendor tries to parse the version of the traceparent
header.
traceparent
header and deletes tracestate
.00
) to parse trace-id
and parent-id
. The vendor will only parse the trace-flags
values supported by this version of this specification and ignore all other values. If parsing fails, the vendor creates a new traceparent
header and deletes the tracestate
. Vendors will set all unparsed / unknown trace-flags
to 0 on outgoing requests.trace-id
and parent-id
. If either trace-id
, parent-id
or trace-flags
are invalid, the vendor creates a new traceparent
header and deletes tracestate
.tracestate
header. If the tracestate
header cannot be parsed the vendor MAY discard the entire header. Invalid tracestate
entries MAY also be discarded.The vendor MUST modify the traceparent
header:
parent-id
: The value of property parent-id
MUST be set to a value representing the ID of the current operation.sampled
: The value of sampled
reflects the caller's recording behavior. The value of the sampled
flag of trace-flags
MAY be set to 1
if the trace data is likely to be recorded or to 0
otherwise. Setting the flag is no guarantee that the trace will be recorded but increases the likeliness of end-to-end recorded traces.The vendor MAY modify the tracestate
header:
The vendor sets the traceparent
and tracestate
header for the outgoing request.
The processing model above describes the complete set of steps for processing trace context headers. There are, however, situations when a vendor might only support a subset of the steps described above. Proxies or messaging middleware MAY decide not to modify the traceparent
headers but remove invalid headers or add additional information to tracestate
.
While trace context is defined for HTTP, the authors acknowledge it is also relevant for other communication protocols. Extensions of this specification, as well as specifications produced by external organizations, define the format of trace context serialization and deserialization for other protocols. Note that these extensions may be at a different maturity level than this specification.
Please refer to the [trace-context-protocols-registry] for the details of trace context implementation for other protocols.
6. Privacy ConsiderationsRequirements to propagate headers to downstream services, as well as storing values of these headers, open up potential privacy concerns. Tracing vendors MUST NOT use traceparent
and tracestate
fields for any personally identifiable or otherwise sensitive information. The only purpose of these fields is to enable trace correlation.
Vendors MUST assess the risk of header abuse. This section provides some considerations and initial assessment of the risk associated with storing and propagating these headers. Tracing vendors may choose to inspect and remove sensitive information from the fields before allowing the tracing system to execute code that can potentially propagate or store these fields. All mutations should, however, conform to the list of mutations defined in this specification.
6.1 Privacy of traceparent fieldThe traceparent
field is comprised of randomly-generated numbers. If a random number generator leverages any user identifiable information like IP address as seed state, this information may be exposed. Random number generators MUST NOT rely on any information that can potentially be user-identifiable.
Another privacy risk of the traceparent
field is the ability to correlate requests made as part of a single transaction. A downstream service may track and correlate two or more requests made in a single transaction and may make assumptions about the identity of the caller of a request based on information from another request.
Note that these privacy concerns of the traceparent
field are theoretical rather than practical. Some services initiating or receiving a request MAY choose to restart a traceparent
field to eliminate those risks completely. Vendors SHOULD find a way to minimize the number of distributed trace restarts to promote interoperability of tracing vendors. Instead of restarts, different techniques may be used. For example, services may define trust boundaries of upstream and downstream connections and the level of exposure that any requests may bring. For instance, a vendor might only restart traceparent
for authentication requests from or to external services.
Services may also define an algorithm and audit mechanism to validate the randomness of incoming or outgoing random numbers in the traceparent
field. Note that this algorithm is services-specific and not a part of this specification. One example might be a temporal algorithm where a reversible hash function is applied to the current clock time. The receiver can validate that the time is within agreed upon boundaries, meaning the random number was generated with the required algorithm and in fact doesn't contain any personally identifiable information.
The tracestate
field may contain any opaque value in any of the keys. The main purpose of this header is to provide additional vendor-specific trace-identification information across different distributed tracing systems.
Vendors MUST NOT include any personally identifiable information in the tracestate
header.
Vendors extremely sensitive to personal information exposure MAY implement selective removal of values corresponding to the unknown keys. Vendors SHOULD NOT mutate the tracestate
field, as it defeats the purpose of allowing multiple tracing systems to collaborate.
When vendors include traceparent
and tracestate
headers in responses, these values may inadvertently be passed to cross-origin callers. Vendors should ensure that they include only these response headers when responding to systems that participated in the trace.
There are two types of potential security risks associated with this specification: information exposure and denial-of-service attacks against the vendor.
Vendors relying on traceparent
and tracestate
headers should also follow all best practices for parsing potentially malicious headers, including checking for header length and content of header values. These practices help to avoid buffer overflow and HTML injection attacks.
As mentioned in the privacy section, information in the traceparent
and tracestate
headers may carry information that can be considered sensitive. For example, traceparent
may allow one request to be correlated to the data sent with another requeest, or the tracestate
header may imply the version of monitoring software used by the caller. This information could potentially be used to create a larger attack.
Application owners should either ensure that no proprietary or confidential information is stored in tracestate
, or they should ensure that tracestate
isn't present in requests to external systems.
When distributed tracing is enabled on a service with a public API and naively continues any trace with the sampled
flag set, a malicious attacker could overwhelm an application with tracing overhead, forge trace-id
collisions that make monitoring data unusable, or run up your tracing bill with your SaaS tracing vendor.
Tracing vendors and platforms should account for these situations and make sure that checks and balances are in place to protect denial of monitoring by malicious or badly authored callers.
One example of such protection may be different tracing behavior for authenticated and unauthenticated requests. Various rate limiters for data recording can also be implemented.
7.3 Other RisksApplication owners need to make sure to test all code paths leading to the sending of traceparent
and tracestate
headers. For example, in single page browser applications, it is typical to make cross-origin requests. If one of these code paths leads to traceparent
and tracestate
headers being sent by cross-origin calls that are restricted using Access-Control-Allow-Headers
[FETCH], it may fail.
This section is non-normative.
This section suggests some best practices to consider when platform or tracing vendor implement trace-id
generation and propagation algorithms. These practices will ensure better interoperability of different systems.
trace-id
The value of trace-id
SHOULD be globally unique. This field is typically used for unique identification of a distributed trace. It is common for distributed traces to span various components, including, for example, cloud services. Cloud services tend to serve variety of clients and have a very high throughput of requests. So global uniqueness of trace-id
is important, even when local uniqueness might seem like a good solution.
trace-id
Randomly generated value of trace-id
SHOULD be preferred over other algorithms of generating a globally unique identifiers. Randomness of trace-id
addresses some security and privacy concerns of exposing unwanted information. Randomness also allows tracing vendors to base sampling decisions on trace-id
field value and avoid propagating an additional sampling context.
As shown in the next section, it is important for trace-id
to carry "uniqueness" and "randomness" in the right part of the trace-id
, for better inter-operability with some existing systems.
trace-id
for compliant platforms with shorter internal identifiers
There are tracing systems which use a trace-id
that is shorter than 16 bytes, which are still willing to adopt this specification.
If such a system is capable of propagating a fully compliant trace-id
, even while still requiring a shorter, non-compliant identifier for internal purposes, the system is encouraged to utilize the tracestate
header to propagate the additional internal identifier. However, if a system would instead prefer to use the internal identifier as the basis for a fully compliant trace-id
, it SHOULD be incorporated at the as rightmost part of a trace-id
. For example, tracing system may receive 234a5bcd543ef3fa53ce929d0e0e4736
as a trace-id
, hovewer internally it will use 53ce929d0e0e4736
as an identifier.
There are tracing systems which are not capable of propagating the entire 16 bytes of a trace-id
. For better interoperability between a fully compliant systems with these existing systems, the following practices are recommended:
trace-id
from a shorter identifier, it SHOULD left pad the original identifier with zeroes. For example, the identifier 53ce929d0e0e4736
, SHOULD be converted to trace-id
value 000000000000000053ce929d0e0e4736
.trace-id
to a shorter identifier, the rightmost part of trace-id
SHOULD be used as this identifier. For instance, if the value of trace-id
was 234a5bcd543ef3fa53ce929d0e0e4736
on an incoming request, tracing system SHOULD use identifier with the value of 53ce929d0e0e4736
.Similar transformations are expected when tracing system converts other distributed trace context propagation formats to W3C Trace Context. Shorter identifiers SHOULD be left padded with zeros when converted to 16 bytes trace-id
and rightmost part of trace-id
SHOULD be used as a shorter identifier.
Note, many existing systems that are not capable of propagating the whole trace-id
will not propagate tracestate
header either. However, such system can still use tracestate
header to propagate additional data that is known by this system. For example, some systems use two flags indicating whether distributed trace needs to be recorded or not. In this case one flag can be send as sampled
flag of traceparent
header and tracestate
can be used to send and receive an additional flag. Compliant systems will propagate this flag along all other key/value pairs. Existing systems which are not capable of tracestate
propagation will truncate all additional values from tracestate
and only pass along that flag.
Thanks to Adrian Cole, Christoph Neumüller, Daniel Khan, Erika Arnold, Fabian Lange, Matthew Wear, Reiley Yang, Ted Young, Tyler Benson, Victor Soares for their contributions to this work.
B. GlossaryThis section is non-normative.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3