Normalizing HTTP header names is ambiguous

[Flarna]

HTTP Span SemConv requires to normalize HTTP header name attributes.

using lower case is fine because HTTP tells to handle header names case insensitive (HTTP/2 requires to them even lowercase).

But replacing - by _ seems problematic because both chars are allowed in http header names.

Therefore this may result in merging/overwrite issues on instrumentation side and unclear interpretation on backend side.

[Oberon00]

Probably we should define which one wins in this case. I'd go for the hyphen one, as the underscore one does not usually occur and could be used by a bad actor to confuse tracing. Although header names to capture are anyways configured one-by-one IIRC, so it should not be a security problem

[Flarna]

I would be in favor of removing this part of the normalization but I fear that ship has sailed or would at least requires a 2.0 release.

[Oberon00]

This normalization (or rather the reversion of it) is very common, and also done by CGI and Python WSGI, so I don't think there will be a problem in practice.

[trask]

I would be in favor of removing this part of the normalization but I fear that ship has sailed or would at least requires a 2.0 release.

It's not too late yet, but soon will be. We will be marking HTTP semantic conventions as stable very soon.

Removing the - to _ part of the normalization seems reasonable to me, and reporting attributes like:

• http.request.header.content-type=["application/json"]
• http.request.header.x-forwarded-for=["1.2.3.4", "1.2.3.5"]

instead of

• http.request.header.content_type=["application/json"]
• http.request.header.x_forwarded_for=["1.2.3.4", "1.2.3.5"]

@open-telemetry/specs-semconv-approvers do we have a reason to try to avoid dashes (-) in attribute names?

I don't see discussion/context of why we would want to do this particular part of the normalization when it was originally proposed in open-telemetry/opentelemetry-specification#1898 (comment)

[trask]

sent #369 to help attract attention and force a decision one way or another on this issue before stabilization