HTTP

• HTTP Attributes
• Deprecated HTTP Attributes

HTTP Attributes

This document defines semantic convention attributes in the HTTP namespace.

Attributes:

Key	Stability	Value Type	Description	Example Values
http.connection.state		string	State of the HTTP connection in the HTTP connection pool.	active; idle
http.request.body.content		any	The content of the HTTP request body, with any content coding indicated by Content-Encoding removed, captured as a string when the request content is textual or as byte array otherwise. [1]	Hello world!; {"foo": "bar"}
http.request.body.size		int	The size of the request payload body in bytes. This is the number of bytes transferred excluding headers and is often, but not always, present as the Content-Length header. For requests using transport encoding, this should be the compressed size.	3495
http.request.header.<key>		string[]	HTTP request headers, <key> being the normalized HTTP Header name (lowercase), the value being the header values. [2]	["application/json"]; ["1.2.3.4", "1.2.3.5"]
http.request.method		string	HTTP request method. [3]	GET; POST; HEAD
http.request.method_original		string	Original HTTP method sent by the client in the request line.	GeT; ACL; foo
http.request.resend_count		int	The ordinal number of request resending attempt (for any reason, including redirects). [4]	3
http.request.size		int	The total size of the request in bytes. This should be the total number of bytes sent over the wire, including the request line (HTTP/1.1), framing (HTTP/2 and HTTP/3), headers, and request body if any.	1437
http.response.body.content		any	The content of the HTTP response body, with any content coding indicated by Content-Encoding removed, captured as a string when the response content is textual or as byte array otherwise. [5]	Hello world!; {"foo": "bar"}
http.response.body.size		int	The size of the response payload body in bytes. This is the number of bytes transferred excluding headers and is often, but not always, present as the Content-Length header. For requests using transport encoding, this should be the compressed size.	3495
http.response.header.<key>		string[]	HTTP response headers, <key> being the normalized HTTP Header name (lowercase), the value being the header values. [6]	["application/json"]; ["abc", "def"]
http.response.size		int	The total size of the response in bytes. This should be the total number of bytes sent over the wire, including the status line (HTTP/1.1), framing (HTTP/2 and HTTP/3), headers, and response body and trailers if any.	1437
http.response.status_code		int	HTTP response status code.	200
http.route		string	The matched route template for the request. This MUST be low-cardinality and include all static path segments, with dynamic path segments represented with placeholders. [7]	/users/:userID?; my-controller/my-action/{id?}

[1] http.request.body.content: Captured value MAY be limited in size and thus value is expected to be truncated in many cases. When an instrumentation applies a byte-based limit while capturing the body as a string, it SHOULD truncate on a character boundary so that the recorded value remains valid text.

Instrumentations MUST NOT capture this attribute by default and MAY provide an option to enable it.

When instrumentations record body, they SHOULD capture the body as string whenever possible as it makes it easier to use in human-readable form, also it allows to implement sanitization if needed.

Textual content is typically detected based on the Content-Type header using heuristics such as checking if the type/subtype (compared case-insensitively, ignoring any parameters) starts with text/, ends with /json, +json, /xml, +xml, /yaml or +yaml, is application/x-www-form-urlencoded, or if the header declares a charset parameter.

Instrumentations that implement request body recording MUST NOT intentionally introduce side effects such as changing stream position or closing body stream independently from the application.

When body is recorded, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP call has ended. The value MUST be either a string or a byte array. Instrumentations MUST NOT record a parsed or otherwise structured representation of the body, and MUST NOT base64-encode binary content into a string value.

[2] http.request.header.<key>: Instrumentations SHOULD require an explicit configuration of which headers are to be captured. Including all request headers can be a security risk - explicit configuration helps avoid leaking sensitive information.

The User-Agent header is already captured in the user_agent.original attribute. Users MAY explicitly configure instrumentations to capture them even though it is not recommended.

The attribute value MUST consist of either multiple header values as an array of strings or a single-item array containing a possibly comma-concatenated string, depending on the way the HTTP library provides access to headers.

Examples:

• A header Content-Type: application/json SHOULD be recorded as the http.request.header.content-type attribute with value ["application/json"].
• A header X-Forwarded-For: 1.2.3.4, 1.2.3.5 SHOULD be recorded as the http.request.header.x-forwarded-for attribute with value ["1.2.3.4", "1.2.3.5"] or ["1.2.3.4, 1.2.3.5"] depending on the HTTP library.

[3] http.request.method: HTTP request method value SHOULD be "known" to the instrumentation. By default, this convention defines "known" methods as the ones listed in RFC9110, the PATCH method defined in RFC5789 and the QUERY method defined in httpbis-safe-method-w-body.

If the HTTP request method is not known to instrumentation, it MUST set the http.request.method attribute to _OTHER.

If the HTTP instrumentation could end up converting valid HTTP request methods to _OTHER, then it MUST provide a way to override the list of known HTTP methods. If this override is done via environment variable, then the environment variable MUST be named OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS and support a comma-separated list of case-sensitive known HTTP methods.

If this override is done via declarative configuration, then the list MUST be configurable via the known_methods property (an array of case-sensitive strings with minimum items 0) under .instrumentation/development.general.http.client and/or .instrumentation/development.general.http.server.

In either case, this list MUST be a full override of the default known methods, it is not a list of known methods in addition to the defaults.

HTTP method names are case-sensitive and http.request.method attribute value MUST match a known HTTP method name exactly. Instrumentations for specific web frameworks that consider HTTP methods to be case insensitive, SHOULD populate a canonical equivalent. Tracing instrumentations that do so, MUST also set http.request.method_original to the original value.

[4] http.request.resend_count: The resend count SHOULD be updated each time an HTTP request gets resent by the client, regardless of what was the cause of the resending (e.g. redirection, authorization failure, 503 Server Unavailable, network issues, or any other).

[5] http.response.body.content: Captured value MAY be limited in size and thus value is expected to be truncated in many cases. When an instrumentation applies a byte-based limit while capturing the body as a string, it SHOULD truncate on a character boundary so that the recorded value remains valid text.

Instrumentations MUST NOT capture this attribute by default and MAY provide an option to enable it.

When instrumentations record body, they SHOULD capture the body as string whenever possible as it makes it easier to use in human-readable form, also it allows to implement sanitization if needed.

Textual content is typically detected based on the Content-Type header using heuristics such as checking if the type/subtype (compared case-insensitively, ignoring any parameters) starts with text/, ends with /json, +json, /xml, +xml, /yaml or +yaml, is application/x-www-form-urlencoded, or if the header declares a charset parameter.

Instrumentations that implement response body recording MUST NOT intentionally introduce side effects such as changing stream position or closing body stream independently from the application.

When body is recorded, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP call has ended. Note that HTTP client spans SHOULD end sometime after the response headers are fully read, which may or may not include reading the response body, so on client spans this attribute is often absent or holds only part of the body.

The value MUST be either a string or a byte array. Instrumentations MUST NOT record a parsed or otherwise structured representation of the body, and MUST NOT base64-encode binary content into a string value.

[6] http.response.header.<key>: Instrumentations SHOULD require an explicit configuration of which headers are to be captured. Including all response headers can be a security risk - explicit configuration helps avoid leaking sensitive information.

Users MAY explicitly configure instrumentations to capture them even though it is not recommended.

The attribute value MUST consist of either multiple header values as an array of strings or a single-item array containing a possibly comma-concatenated string, depending on the way the HTTP library provides access to headers.

Examples:

• A header Content-Type: application/json header SHOULD be recorded as the http.request.response.content-type attribute with value ["application/json"].
• A header My-custom-header: abc, def header SHOULD be recorded as the http.response.header.my-custom-header attribute with value ["abc", "def"] or ["abc, def"] depending on the HTTP library.

[7] http.route: MUST NOT be populated when this is not supported by the HTTP server framework as the route attribute should have low-cardinality and the URI path can NOT substitute it. SHOULD include the application root if there is one.

A static path segment is a part of the route template with a fixed, low-cardinality value. This includes literal strings like /users/ and placeholders that are constrained to a finite, predefined set of values, e.g. {controller} or {action}.

A dynamic path segment is a placeholder for a value that can have high cardinality and is not constrained to a predefined list like static path segments.

Instrumentations SHOULD use routing information provided by the corresponding web framework. They SHOULD pick the most precise source of routing information and MAY support custom route formatting. Instrumentations SHOULD document the format and the API used to obtain the route string.

---

http.connection.state has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
active	active state.
idle	idle state.

---

http.request.method has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
_OTHER	Any HTTP method that the instrumentation has no prior knowledge of.
CONNECT	CONNECT method.
DELETE	DELETE method.
GET	GET method.
HEAD	HEAD method.
OPTIONS	OPTIONS method.
PATCH	PATCH method.
POST	POST method.
PUT	PUT method.
QUERY	QUERY method.
TRACE	TRACE method.

Deprecated HTTP Attributes

Describes deprecated HTTP attributes.

Attributes:

Key	Stability	Value Type	Description	Example Values
http.client_ip	Replaced by client.address.	string	Deprecated, use client.address instead.	83.164.160.102
http.flavor	Split into network.protocol.name and network.protocol.version	string	Deprecated, use network.protocol.name and network.protocol.version instead.	1.0; 1.1; 2.0
http.host	Replaced by one of server.address, client.address or http.request.header.host, depending on the usage.	string	Deprecated, use one of server.address, client.address or http.request.header.host instead, depending on the usage.	www.example.org
http.method	Replaced by http.request.method.	string	Deprecated, use http.request.method instead.	GET; POST; HEAD
http.request_content_length	Replaced by http.request.header.content-length.	int	Deprecated, use http.request.header.content-length instead.	3495
http.request_content_length_uncompressed	Replaced by http.request.body.size.	int	Deprecated, use http.request.body.size instead.	5493
http.response_content_length	Replaced by http.response.header.content-length.	int	Deprecated, use http.response.header.content-length instead.	3495
http.response_content_length_uncompressed	Replaced by http.response.body.size.	int	Deprecated, use http.response.body.size instead.	5493
http.scheme	Replaced by url.scheme.	string	Deprecated, use url.scheme instead.	http; https
http.server_name	Replaced by server.address.	string	Deprecated, use server.address instead.	example.com
http.status_code	Replaced by http.response.status_code.	int	Deprecated, use http.response.status_code instead.	200
http.target	Split to url.path and url.query.	string	Deprecated, use url.path and url.query instead.	/search?q=OpenTelemetry#SemConv
http.url	Replaced by url.full.	string	Deprecated, use url.full instead.	https://www.foo.bar/search?q=OpenTelemetry#SemConv
http.user_agent	Replaced by user_agent.original.	string	Deprecated, use user_agent.original instead.	CERN-LineMode/2.15 libwww/2.17b3; Mozilla/5.0 (iPhone; CPU iPhone OS 14_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1

---

http.flavor has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
1.0	HTTP/1.0
1.1	HTTP/1.1
2.0	HTTP/2
3.0	HTTP/3
QUIC	QUIC protocol.
SPDY	SPDY protocol.