Propagation - Getter handling of multi-value headers/attributes

[tylerbenson]

Some formats (http) allow for a single key to return multiple values. This is used in w3c trace-context which we plan to support:

Tracestate MAY be sent or received as multiple header fields. ... The tracestate header SHOULD be sent as a single field when possible, but MAY be split into multiple header fields.

We don't currently specify this requirement in our spec:
https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-propagators.md#getter-argument

As a consequence, we aren't handling that well in java, and likely other languages:
https://github.com/open-telemetry/opentelemetry-java/blob/v0.2.x/api/src/main/java/io/opentelemetry/context/propagation/HttpTextFormat.java#L123

How do we want to handle this? Should we push responsibility for joining them properly to the Getter, or should the API support returning multiple values?

[tylerbenson]

In the spec call, there was some consensus that we should handle multiple values within the getter. This implies that the propagator will always need implicitly handle the possibility of multiple values rather than explicitly dealing with a list.

@bogdandrutu is this a good summary? Think the spec should be changed or should I just close this issue?

[carlosalberto]

Bringing this over from #424 :

Jaeger context cannot be parsed using only the Getter interface. Here's an example of Jaeger context:

uber-trace-id: <some string, similar to W3C trace context>
uberctx-tenancy: test
uberctx-user: Yuri

The trace context has a fixed key name uber-trace-id, but baggage is encoded using variable header names uberctx-{baggage-key}.

Also, the W3C tracestate header may be split into multiple entries (repeated headers).

In the OpenTracing there was an iterator over all headers in order to handle this case, not just a Getter. Consider switching to an iterator-based approach.

[tsloughter]

Does the Otel spec have to support Uber's baggage? Is that considered a OpenTracing bridge requirement?

[tylerbenson]

If we are going to adopt this, instead of an iterator approach, I suggest exposing two methods:

• getting a list or iterator of header names/keys
• getting the value(s) of a single header

implementing the pure iterator interface in opentracing was inefficient and resulted in additional instrumentation complexity.