OTLP exporters should not percent decode the key when parsing HEADERS env vars

[pellared]

The OTLP exporters SHOULD NOT percent decode the header keys when parsing OTEL_EXPORTER_OTLP_HEADERS, OTEL_EXPORTER_OTLP_TRACES_HEADERS, OTEL_EXPORTER_OTLP_METRICS_HEADERS, OTEL_EXPORTER_OTLP_LOGS_HEADERS env vars. Moreover, only valid header keys should be parsed.

Current behavior:

opentelemetry-go/exporters/otlp/otlptrace/otlptracegrpc/internal/envconfig/envconfig.go

Lines 166 to 170 in 29bdfd2

	name, err := url.PathUnescape(n)
	if err != nil {
	global.Error(err, "escape header key", "key", n)
	continue
	}

The specification says https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#specifying-headers-via-environment-variables:

The OTEL_EXPORTER_OTLP_HEADERS, OTEL_EXPORTER_OTLP_TRACES_HEADERS, OTEL_EXPORTER_OTLP_METRICS_HEADERS, OTEL_EXPORTER_OTLP_LOGS_HEADERS environment variables will contain a list of key value pairs, and these are expected to be represented in a format matching to the W3C Baggage, except that additional semi-colon delimited metadata is not supported, i.e.: key1=value1,key2=value2. All attribute values MUST be considered strings.

From W3C Baggage spec https://www.w3.org/TR/baggage/#key:

A token which identifies a value in the baggage. token is defined in RFC7230, Section 3.2.6. Leading and trailing whitespaces (OWS) are allowed and are not considered to be a part of the key.

NOTE
Though the baggage header is a [UTF-8] encoded [UNICODE] string, key is limited to the ASCII code points allowed by the definition of token in [RFC7230]. This is due to the implementation details of stable implementations prior to the writing of this specification.

There is nothing about percent encoding. Only the values are supposed to be percent decoded.

Notice that the implementation should also make sure that only valid key characters are used.

[zhihali]

I will open a PR for it...

[zhihali]

the OTLPlog should be updated as well, I have raised an issue related #5722, and will implement a fix soon