Should HTTP server.address and server.port prioritize Host header over virtual host name?

[trask]

Since one of the motivations for these attributes on the server side:

• server.address
• server.port
• url.path
• url.query
• url.scheme

is to reconstruct the original URL, does it make sense to prioritize capturing server.address and server.port from the Host header instead of the current state of prioritizing the virtual host name?

(and since we have more clarity on these being logical attributes now, and since we can introduce more lower-level attributes to capture virtual host name / port in the future as needed)

here's the current definition of server.address (as captured on the server side):

semantic-conventions/model/http-common.yaml

Lines 70 to 80 in b127e12

	- ref: server.address
	brief: >
	Name of the local HTTP server that received the request.
	note: |
	Determined by using the first of the following that applies
	- The [primary server name](/docs/http/http-spans.md#http-server-definitions) of the matched virtual host. MUST only
	include host identifier.
	- Host identifier of the [request target](https://www.rfc-editor.org/rfc/rfc9110.html#target.resource)
	if it's sent in absolute-form.
	- Host identifier of the `Host` header

[Oberon00]

IMHO: No, the Host header should not be prioritized. Unfortunately, it often contains bogus content, and it can be captured separately in http.request.header.host (at least in HTTP/1, in HTTP/2 it might become http.request.header.:authority? Probably the header spec needs an update for HTTP/2 pseudo-headers)

Doing a bit of PR archeology, it seems it was @lmolkova who defined this priority order in open-telemetry/opentelemetry-specification#2469 and declared that to be the order to find the "best known server name". I think it is a very reasonable priority order.

[lmolkova]

Agree with @Oberon00. Reverse proxies don't always preserve the original host header (and custom configuration can put anything there).

In my mental model, since the "primary server name" is essentially user-configurable, this is the way for users to force server.address to be something they want.

Something we should probably do:

• change "The primary server name of the matched virtual host" to something like "Explicit user configuration (if provided) or a primary server name"
• add "Original host used by the client such as host component of Forwarded header, X-Forwarded-Host or similar" to come 3rd before Host header

WDYT?

[Oberon00]

I agree that "virtual host" verbiage could/should probably be removed and replaced by something simpler.

One thing that just occured to me: server.address is also used as metric attribute for HTTP server metric. A bad Host header could easily cause a cardinality explosion there. So that is a no-go also for that reason I believe. https://opentelemetry.io/docs/specs/otel/metrics/semantic_conventions/http-metrics/#metric-httpserverduration

Given that, "or a primary server name" might need an additional hint that it must still be something that needs to be low cardinality.

[trask]

A bad Host header could easily cause a cardinality explosion there.

this discussion led me to a similar worry, let me know if you think #401 is sufficient

[trask]

Explicit user configuration (if provided) or a primary server name

are you thinking instrumentation configuration? do we need to mention that? or is this important enough to include something like "instrumentation SHOULD provide configuration"

moving this question to #414

[trask]

Closing this issue, I think the original question has been answered, and there are follow-up issues and PRs for the other discussion items:

• Consider X-Forwarded-Host / Forwarded when capturing server.address and server.port #408
• Simplify primary server name section of HTTP semconv server.address #414
• Add cardinality warning about two opt-in HTTP metric attributes #401