The URI scheme component identifying the used protocol. [2]
http; https
Required
[2]: The scheme of the original client request, if known (e.g. from Forwarded#proto, X-Forwarded-Proto, or a similar header). Otherwise, the scheme of the immediate peer request.
Since generally in any modern environment the webserver app is not going to be terminating TLS itself, the spec tells us to lean on the X-Forwarded-Proto and Forwarded headers for the information.
The middleware needs to:
parse each header to get the protocol out of it
assign the result to url.scheme attribute label on each request
The docs do not explicitly say this but I would assume we should give precedence to Forwarded since it is a real standard, while X-Forwarded-Proto is a "de-facto standard" which seems unlikely to ever be promoted from that status, as Forwarded covers the same info.
Given that this is an HTTP server middleware, we can fall back to http or just splitting it from the URL if it's not present in the headers, as described: Otherwise, the scheme of the immediate peer request.
https://opentelemetry.io/docs/specs/semconv/http/http-metrics/#http-server
http;httpsSince generally in any modern environment the webserver app is not going to be terminating TLS itself, the spec tells us to lean on the
X-Forwarded-ProtoandForwardedheaders for the information.The middleware needs to:
url.schemeattribute label on each requestThe docs do not explicitly say this but I would assume we should give precedence to
Forwardedsince it is a real standard, whileX-Forwarded-Protois a "de-facto standard" which seems unlikely to ever be promoted from that status, asForwardedcovers the same info.Given that this is an HTTP server middleware, we can fall back to
httpor just splitting it from the URL if it's not present in the headers, as described: Otherwise, the scheme of the immediate peer request.