From f59225da9987c2004a63a07cf9bfcfca342f9a05 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Mon, 9 Mar 2026 17:36:50 +0100 Subject: [PATCH 01/17] add http request body content --- model/http/registry.yaml | 17 +++++++++++++++++ model/http/spans.yaml | 2 ++ 2 files changed, 19 insertions(+) diff --git a/model/http/registry.yaml b/model/http/registry.yaml index d91c2d8762..b4036b40b9 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -204,3 +204,20 @@ groups: brief: State of the HTTP connection in the HTTP connection pool. stability: development examples: ["active", "idle"] + - id: http.request.body.content + type: any + brief: > + The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. + + Captured value MUST be limited in size and thus value is expected to be truncated in many cases. + Instrumentations MUST provide configuration options to control the maximum captured body size. + + Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + + Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics + such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + + examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] + stability: development diff --git a/model/http/spans.yaml b/model/http/spans.yaml index dd49374df9..586da16210 100644 --- a/model/http/spans.yaml +++ b/model/http/spans.yaml @@ -141,3 +141,5 @@ groups: requirement_level: opt_in - ref: user_agent.synthetic.type requirement_level: opt_in + - ref: http.request.body.content + requirement_level: opt_in From f3414ad78731822ea9e9e6b35975108dcfd3f0d9 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Mon, 9 Mar 2026 17:37:05 +0100 Subject: [PATCH 02/17] add changelog --- .chloggen/http-request-response-body.yaml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 .chloggen/http-request-response-body.yaml diff --git a/.chloggen/http-request-response-body.yaml b/.chloggen/http-request-response-body.yaml new file mode 100644 index 0000000000..6ab8fd42e6 --- /dev/null +++ b/.chloggen/http-request-response-body.yaml @@ -0,0 +1,22 @@ +# Use this changelog template to create an entry for release notes. +# +# If your change doesn't affect end users you should instead start +# your pull request title with [chore] or use the "Skip Changelog" label. + +# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' +change_type: 'enhancement' + +# The name of the area of concern in the attributes-registry, (e.g. http, cloud, db) +component: 'http' + +# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). +note: "add 'http.request.body.content` to capture http request body" + +# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. +# The values here must be integers. +issues: [ 857 ] + +# (Optional) One or more lines of additional information to render under the primary note. +# These lines will be padded with 2 spaces and then inserted directly into the document. +# Use pipe (|) for multiline entries. +subtext: From 2e6d1ba8e6826ccccd68f83fa6aada6780ec5ef5 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Fri, 13 Mar 2026 12:52:34 +0100 Subject: [PATCH 03/17] update to cover request+response client+server --- .chloggen/http-request-response-body.yaml | 2 +- model/http/registry.yaml | 17 +++++++++++++++++ model/http/spans.yaml | 6 ++++++ 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/.chloggen/http-request-response-body.yaml b/.chloggen/http-request-response-body.yaml index 6ab8fd42e6..f1f1ad8080 100644 --- a/.chloggen/http-request-response-body.yaml +++ b/.chloggen/http-request-response-body.yaml @@ -10,7 +10,7 @@ change_type: 'enhancement' component: 'http' # A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). -note: "add 'http.request.body.content` to capture http request body" +note: "add `http.request.body.content` and `http.response.body.content` to capture http request and response body" # Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. # The values here must be integers. diff --git a/model/http/registry.yaml b/model/http/registry.yaml index b4036b40b9..9a7341e558 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -221,3 +221,20 @@ groups: examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] stability: development + - id: http.response.body.content + type: any + brief: > + The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. + + Captured value MUST be limited in size and thus value is expected to be truncated in many cases. + Instrumentations MUST provide configuration options to control the maximum captured body size. + + Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + + Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics + such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + + examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] + stability: development diff --git a/model/http/spans.yaml b/model/http/spans.yaml index 586da16210..9765ba1f9a 100644 --- a/model/http/spans.yaml +++ b/model/http/spans.yaml @@ -64,6 +64,10 @@ groups: requirement_level: opt_in - ref: user_agent.synthetic.type requirement_level: opt_in + - ref: http.request.body.content + requirement_level: opt_in + - ref: http.response.body.content + requirement_level: opt_in - id: span.http.server type: span @@ -143,3 +147,5 @@ groups: requirement_level: opt_in - ref: http.request.body.content requirement_level: opt_in + - ref: http.response.body.content + requirement_level: opt_in From d9480afc07e2e5a10f331d8b564ad292750f1f52 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Fri, 13 Mar 2026 13:00:44 +0100 Subject: [PATCH 04/17] update markdown --- docs/http/http-spans.md | 20 ++++++++++++++++++++ docs/registry/attributes/http.md | 10 ++++++++++ 2 files changed, 30 insertions(+) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index a005f26bd3..cf29b6206f 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -163,9 +163,19 @@ There are two ways HTTP client spans can be implemented in an instrumentation: | [`network.peer.address`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | Peer address of the network connection - IP address or Unix domain socket name. | `10.1.2.80`; `/tmp/my.sock` | | [`network.peer.port`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` If `network.peer.address` is set. | int | Peer port number of the network connection. | `65123` | | [`network.protocol.version`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | The actual version of the protocol used for network communication. [10] | `1.0`; `1.1`; `2`; `3` | +| [`http.request.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. +Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.request.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [11] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | [`http.request.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. +Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.response.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [12] | `["application/json"]`; `["abc", "def"]` | | [`http.response.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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` | @@ -484,9 +494,19 @@ This span represents an inbound HTTP request. | [`server.address`](/docs/registry/attributes/server.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | Name of the local HTTP server that received the request. [13] | `example.com`; `10.1.2.80`; `/tmp/my.sock` | | [`user_agent.original`](/docs/registry/attributes/user-agent.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | Value of the [HTTP User-Agent](https://www.rfc-editor.org/rfc/rfc9110.html#field.user-agent) header sent by the client. | `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`; `YourApp/1.0.0 grpc-java-okhttp/1.27.2` | | [`client.port`](/docs/registry/attributes/client.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | int | The port of whichever client was captured in `client.address`. [14] | `65123` | +| [`http.request.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. +Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.request.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [15] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | [`http.request.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. +Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.response.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [16] | `["application/json"]`; `["abc", "def"]` | | [`http.response.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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` | diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 5f48f1d314..00fb6a425f 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -15,12 +15,22 @@ This document defines semantic convention attributes in the HTTP namespace. | Key | Stability | Value Type | Description | Example Values | | --- | --- | --- | --- | --- | | `http.connection.state` | ![Development](https://img.shields.io/badge/-development-blue) | string | State of the HTTP connection in the HTTP connection pool. | `active`; `idle` | +| `http.request.body.content` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. +Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | `http.request.body.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | `http.request.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [1] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | `http.request.method` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string | HTTP request method. [2] | `GET`; `POST`; `HEAD` | | `http.request.method_original` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string | Original HTTP method sent by the client in the request line. | `GeT`; `ACL`; `foo` | | `http.request.resend_count` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | int | The ordinal number of request resending attempt (for any reason, including redirects). [3] | `3` | | `http.request.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. +Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | `http.response.body.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | `http.response.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [4] | `["application/json"]`; `["abc", "def"]` | | `http.response.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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` | From 050b6399f324b0bca929ad69d5d5b41d814ad760 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Fri, 13 Mar 2026 13:15:28 +0100 Subject: [PATCH 05/17] use note to fix markdown table length --- docs/http/http-spans.md | 100 ++++++++++++++++++++++++--------------- model/http/registry.yaml | 6 +-- 2 files changed, 64 insertions(+), 42 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index cf29b6206f..c1fd93ece5 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -163,27 +163,19 @@ There are two ways HTTP client spans can be implemented in an instrumentation: | [`network.peer.address`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | Peer address of the network connection - IP address or Unix domain socket name. | `10.1.2.80`; `/tmp/my.sock` | | [`network.peer.port`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` If `network.peer.address` is set. | int | Peer port number of the network connection. | `65123` | | [`network.protocol.version`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | The actual version of the protocol used for network communication. [10] | `1.0`; `1.1`; `2`; `3` | -| [`http.request.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. -Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. -Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| [`http.request.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. [11] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.request.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | -| [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [11] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | +| [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [12] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | [`http.request.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. -Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. -Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| [`http.response.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. [13] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.response.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | -| [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [12] | `["application/json"]`; `["abc", "def"]` | +| [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [14] | `["application/json"]`; `["abc", "def"]` | | [`http.response.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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` | -| [`network.transport`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | [OSI transport layer](https://wikipedia.org/wiki/Transport_layer) or [inter-process communication method](https://wikipedia.org/wiki/Inter-process_communication). [13] | `tcp`; `udp` | +| [`network.transport`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | [OSI transport layer](https://wikipedia.org/wiki/Transport_layer) or [inter-process communication method](https://wikipedia.org/wiki/Inter-process_communication). [15] | `tcp`; `udp` | | [`url.scheme`](/docs/registry/attributes/url.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | The [URI scheme](https://www.rfc-editor.org/rfc/rfc3986#section-3.1) component identifying the used protocol. | `http`; `https` | -| [`url.template`](/docs/registry/attributes/url.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | string | The low-cardinality template of an [absolute path reference](https://www.rfc-editor.org/rfc/rfc3986#section-4.2). [14] | `/users/{id}`; `/users/:id`; `/users?id={id}` | +| [`url.template`](/docs/registry/attributes/url.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | string | The low-cardinality template of an [absolute path reference](https://www.rfc-editor.org/rfc/rfc3986#section-4.2). [16] | `/users/{id}`; `/users/:id`; `/users?id={id}` | | [`user_agent.original`](/docs/registry/attributes/user-agent.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | Value of the [HTTP User-Agent](https://www.rfc-editor.org/rfc/rfc9110.html#field.user-agent) header sent by the client. | `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`; `YourApp/1.0.0 grpc-java-okhttp/1.27.2` | -| [`user_agent.synthetic.type`](/docs/registry/attributes/user-agent.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | string | Specifies the category of synthetic traffic, such as tests or bots. [15] | `bot`; `test` | +| [`user_agent.synthetic.type`](/docs/registry/attributes/user-agent.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | string | Specifies the category of synthetic traffic, such as tests or bots. [17] | `bot`; `test` | **[1] `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](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods), @@ -283,7 +275,17 @@ If the request has completed successfully, instrumentations SHOULD NOT set `erro **[10] `network.protocol.version`:** If protocol version is subject to negotiation (for example using [ALPN](https://www.rfc-editor.org/rfc/rfc7301.html)), this attribute SHOULD be set to the negotiated version. If the actual protocol version is not known, this attribute SHOULD NOT be set. -**[11] `http.request.header.`:** Instrumentations SHOULD require an explicit configuration of which headers are to be captured. +**[11] `http.request.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. +Instrumentations MUST provide configuration options to control the maximum captured body size. + +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics +such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + +**[12] `http.request.header.`:** 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. @@ -300,7 +302,17 @@ Examples: - 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. -**[12] `http.response.header.`:** Instrumentations SHOULD require an explicit configuration of which headers are to be captured. +**[13] `http.response.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. +Instrumentations MUST provide configuration options to control the maximum captured body size. + +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics +such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + +**[14] `http.response.header.`:** 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. @@ -316,11 +328,11 @@ Examples: - 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. -**[13] `network.transport`:** Generally `tcp` for `HTTP/1.0`, `HTTP/1.1`, and `HTTP/2`. Generally `udp` for `HTTP/3`. Other obscure implementations are possible. +**[15] `network.transport`:** Generally `tcp` for `HTTP/1.0`, `HTTP/1.1`, and `HTTP/2`. Generally `udp` for `HTTP/3`. Other obscure implementations are possible. -**[14] `url.template`:** The `url.template` MUST have low cardinality. It is not usually available on HTTP clients, but may be known by the application or specialized HTTP instrumentation. +**[16] `url.template`:** The `url.template` MUST have low cardinality. It is not usually available on HTTP clients, but may be known by the application or specialized HTTP instrumentation. -**[15] `user_agent.synthetic.type`:** This attribute MAY be derived from the contents of the `user_agent.original` attribute. Components that populate the attribute are responsible for determining what they consider to be synthetic bot or test traffic. This attribute can either be set for self-identification purposes, or on telemetry detected to be generated as a result of a synthetic request. This attribute is useful for distinguishing between genuine client traffic and synthetic traffic generated by bots or tests. +**[17] `user_agent.synthetic.type`:** This attribute MAY be derived from the contents of the `user_agent.original` attribute. Components that populate the attribute are responsible for determining what they consider to be synthetic bot or test traffic. This attribute can either be set for self-identification purposes, or on telemetry detected to be generated as a result of a synthetic request. This attribute is useful for distinguishing between genuine client traffic and synthetic traffic generated by bots or tests. The following attributes can be important for making sampling decisions and SHOULD be provided **at span creation time** (if provided at all): @@ -494,26 +506,18 @@ This span represents an inbound HTTP request. | [`server.address`](/docs/registry/attributes/server.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | Name of the local HTTP server that received the request. [13] | `example.com`; `10.1.2.80`; `/tmp/my.sock` | | [`user_agent.original`](/docs/registry/attributes/user-agent.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Recommended` | string | Value of the [HTTP User-Agent](https://www.rfc-editor.org/rfc/rfc9110.html#field.user-agent) header sent by the client. | `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`; `YourApp/1.0.0 grpc-java-okhttp/1.27.2` | | [`client.port`](/docs/registry/attributes/client.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | int | The port of whichever client was captured in `client.address`. [14] | `65123` | -| [`http.request.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. -Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. -Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| [`http.request.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. [15] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.request.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | -| [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [15] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | +| [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [16] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | [`http.request.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. -Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. -Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| [`http.response.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. [17] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.response.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | -| [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [16] | `["application/json"]`; `["abc", "def"]` | +| [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [18] | `["application/json"]`; `["abc", "def"]` | | [`http.response.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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` | | [`network.local.address`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | Local socket address. Useful in case of a multi-IP host. | `10.1.2.80`; `/tmp/my.sock` | | [`network.local.port`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | int | Local socket port. Useful in case of a multi-port host. | `65123` | -| [`network.transport`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | [OSI transport layer](https://wikipedia.org/wiki/Transport_layer) or [inter-process communication method](https://wikipedia.org/wiki/Inter-process_communication). [17] | `tcp`; `udp` | -| [`user_agent.synthetic.type`](/docs/registry/attributes/user-agent.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | string | Specifies the category of synthetic traffic, such as tests or bots. [18] | `bot`; `test` | +| [`network.transport`](/docs/registry/attributes/network.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string | [OSI transport layer](https://wikipedia.org/wiki/Transport_layer) or [inter-process communication method](https://wikipedia.org/wiki/Inter-process_communication). [19] | `tcp`; `udp` | +| [`user_agent.synthetic.type`](/docs/registry/attributes/user-agent.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | string | Specifies the category of synthetic traffic, such as tests or bots. [20] | `bot`; `test` | **[1] `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](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods), @@ -610,7 +614,17 @@ When a query string value is redacted, the query string key SHOULD still be pres **[14] `client.port`:** When observed from the server side, and when communicating through an intermediary, `client.port` SHOULD represent the client port behind any intermediaries, for example proxies, if it's available. -**[15] `http.request.header.`:** Instrumentations SHOULD require an explicit configuration of which headers are to be captured. +**[15] `http.request.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. +Instrumentations MUST provide configuration options to control the maximum captured body size. + +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics +such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + +**[16] `http.request.header.`:** 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. @@ -627,7 +641,17 @@ Examples: - 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. -**[16] `http.response.header.`:** Instrumentations SHOULD require an explicit configuration of which headers are to be captured. +**[17] `http.response.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. +Instrumentations MUST provide configuration options to control the maximum captured body size. + +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics +such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + +**[18] `http.response.header.`:** 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. @@ -643,9 +667,9 @@ Examples: - 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. -**[17] `network.transport`:** Generally `tcp` for `HTTP/1.0`, `HTTP/1.1`, and `HTTP/2`. Generally `udp` for `HTTP/3`. Other obscure implementations are possible. +**[19] `network.transport`:** Generally `tcp` for `HTTP/1.0`, `HTTP/1.1`, and `HTTP/2`. Generally `udp` for `HTTP/3`. Other obscure implementations are possible. -**[18] `user_agent.synthetic.type`:** This attribute MAY be derived from the contents of the `user_agent.original` attribute. Components that populate the attribute are responsible for determining what they consider to be synthetic bot or test traffic. This attribute can either be set for self-identification purposes, or on telemetry detected to be generated as a result of a synthetic request. This attribute is useful for distinguishing between genuine client traffic and synthetic traffic generated by bots or tests. +**[20] `user_agent.synthetic.type`:** This attribute MAY be derived from the contents of the `user_agent.original` attribute. Components that populate the attribute are responsible for determining what they consider to be synthetic bot or test traffic. This attribute can either be set for self-identification purposes, or on telemetry detected to be generated as a result of a synthetic request. This attribute is useful for distinguishing between genuine client traffic and synthetic traffic generated by bots or tests. The following attributes can be important for making sampling decisions and SHOULD be provided **at span creation time** (if provided at all): diff --git a/model/http/registry.yaml b/model/http/registry.yaml index 9a7341e558..c5243814c9 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -208,7 +208,7 @@ groups: type: any brief: > The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. - + note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. @@ -218,14 +218,13 @@ groups: Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. - examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] stability: development - id: http.response.body.content type: any brief: > The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. - + note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. @@ -235,6 +234,5 @@ groups: Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. - examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] stability: development From c5e0d548b3ec37c5e4b2bc918c80c5cb3d7c793b Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Fri, 13 Mar 2026 13:24:36 +0100 Subject: [PATCH 06/17] update registry --- docs/registry/attributes/http.md | 52 ++++++++++++++++++++------------ 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 00fb6a425f..9f6c9d3761 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -15,29 +15,31 @@ This document defines semantic convention attributes in the HTTP namespace. | Key | Stability | Value Type | Description | Example Values | | --- | --- | --- | --- | --- | | `http.connection.state` | ![Development](https://img.shields.io/badge/-development-blue) | string | State of the HTTP connection in the HTTP connection pool. | `active`; `idle` | -| `http.request.body.content` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. -Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. -Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| `http.request.body.content` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. [1] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | `http.request.body.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | -| `http.request.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [1] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | -| `http.request.method` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string | HTTP request method. [2] | `GET`; `POST`; `HEAD` | +| `http.request.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP request headers, `` 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` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string | HTTP request method. [3] | `GET`; `POST`; `HEAD` | | `http.request.method_original` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string | Original HTTP method sent by the client in the request line. | `GeT`; `ACL`; `foo` | -| `http.request.resend_count` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | int | The ordinal number of request resending attempt (for any reason, including redirects). [3] | `3` | +| `http.request.resend_count` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | int | The ordinal number of request resending attempt (for any reason, including redirects). [4] | `3` | | `http.request.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. -Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. -Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| `http.response.body.content` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. [5] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | `http.response.body.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | -| `http.response.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [4] | `["application/json"]`; `["abc", "def"]` | +| `http.response.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [6] | `["application/json"]`; `["abc", "def"]` | | `http.response.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | int | [HTTP response status code](https://tools.ietf.org/html/rfc7231#section-6). | `200` | -| `http.route` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | 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. [5] | `/users/:userID?`; `my-controller/my-action/{id?}` | +| `http.route` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | 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 MUST be limited in size and thus value is expected to be truncated in many cases. +Instrumentations MUST provide configuration options to control the maximum captured body size. + +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics +such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -**[1] `http.request.header.`:** Instrumentations SHOULD require an explicit configuration of which headers are to be captured. +**[2] `http.request.header.`:** 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. @@ -54,7 +56,7 @@ Examples: - 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. -**[2] `http.request.method`:** HTTP request method value SHOULD be "known" to the instrumentation. +**[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](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods), the PATCH method defined in [RFC5789](https://www.rfc-editor.org/rfc/rfc5789.html) and the QUERY method defined in [httpbis-safe-method-w-body](https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/?include_text=1). @@ -77,9 +79,19 @@ HTTP method names are case-sensitive and `http.request.method` attribute value M 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. -**[3] `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). +**[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 MUST be limited in size and thus value is expected to be truncated in many cases. +Instrumentations MUST provide configuration options to control the maximum captured body size. + +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. + +Instrumentations 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics +such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -**[4] `http.response.header.`:** Instrumentations SHOULD require an explicit configuration of which headers are to be captured. +**[6] `http.response.header.`:** 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. @@ -95,7 +107,7 @@ Examples: - 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. -**[5] `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. +**[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](/docs/http/http-spans.md#http-server-definitions) 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 From 0ddac78cdb479dbcc07e89517cf7cd3b46cba1ae Mon Sep 17 00:00:00 2001 From: SylvainJuge <763082+SylvainJuge@users.noreply.github.com> Date: Mon, 30 Mar 2026 17:36:37 +0200 Subject: [PATCH 07/17] Apply suggestions from code review Co-authored-by: Liudmila Molkova --- model/http/registry.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/model/http/registry.yaml b/model/http/registry.yaml index c5243814c9..d772a3a185 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -223,7 +223,7 @@ groups: - id: http.response.body.content type: any brief: > - The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. + The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. Instrumentations MUST provide configuration options to control the maximum captured body size. From 56bacd9a44946d713ab1a7ae857fda9f9b0a5af4 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Tue, 21 Apr 2026 08:38:19 +0200 Subject: [PATCH 08/17] update markdown --- docs/http/http-spans.md | 4 ++-- docs/registry/attributes/http.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index c1fd93ece5..2385bee6f3 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -167,7 +167,7 @@ There are two ways HTTP client spans can be implemented in an instrumentation: | [`http.request.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [12] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | [`http.request.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. [13] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| [`http.response.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. [13] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.response.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [14] | `["application/json"]`; `["abc", "def"]` | | [`http.response.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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` | @@ -510,7 +510,7 @@ This span represents an inbound HTTP request. | [`http.request.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.request.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP request headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [16] | `["application/json"]`; `["1.2.3.4", "1.2.3.5"]` | | [`http.request.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. [17] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| [`http.response.body.content`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. [17] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | [`http.response.body.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | [`http.response.header.`](/docs/registry/attributes/http.md) | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | `Opt-In` | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [18] | `["application/json"]`; `["abc", "def"]` | | [`http.response.size`](/docs/registry/attributes/http.md) | ![Development](https://img.shields.io/badge/-development-blue) | `Opt-In` | 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` | diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 9f6c9d3761..2655350b7f 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -22,7 +22,7 @@ This document defines semantic convention attributes in the HTTP namespace. | `http.request.method_original` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string | Original HTTP method sent by the client in the request line. | `GeT`; `ACL`; `foo` | | `http.request.resend_count` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | int | The ordinal number of request resending attempt (for any reason, including redirects). [4] | `3` | | `http.request.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as binary otherwise. [5] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | +| `http.response.body.content` | ![Development](https://img.shields.io/badge/-development-blue) | any | The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. [5] | `Hello world!`; `{"foo: "bar"}`; `aGVsbG8=` | | `http.response.body.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-length) header. For requests using transport encoding, this should be the compressed size. | `3495` | | `http.response.header.` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | string[] | HTTP response headers, `` being the normalized HTTP Header name (lowercase), the value being the header values. [6] | `["application/json"]`; `["abc", "def"]` | | `http.response.size` | ![Development](https://img.shields.io/badge/-development-blue) | 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` | From e21fdfec7be49f9747d7f5f5eec961ca0aea7939 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 4 Jun 2026 10:21:53 +0200 Subject: [PATCH 09/17] modify http body limit --- model/http/registry.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/model/http/registry.yaml b/model/http/registry.yaml index d772a3a185..a900154248 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -210,7 +210,8 @@ groups: The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. - Instrumentations MUST provide configuration options to control the maximum captured body size. + In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), + instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. @@ -226,7 +227,8 @@ groups: The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. - Instrumentations MUST provide configuration options to control the maximum captured body size. + In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), + instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. From 4fe735c1a04ced19a9bd4ba5a19f3a0ae2d3b30e Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 4 Jun 2026 10:35:55 +0200 Subject: [PATCH 10/17] add mention of brittle HTTP body capture --- model/http/registry.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/model/http/registry.yaml b/model/http/registry.yaml index a900154248..216d330fc6 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -217,6 +217,8 @@ groups: Instrumentations 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. + Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, configuration and usage of the instrumented HTTP client and server libraries. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] @@ -234,6 +236,11 @@ groups: Instrumentations 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. + Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, configuration and usage of the instrumented HTTP client and server libraries. + + For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP [client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. + This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] From 504e42e913ee5bc41b7ead63d2e797d9dcbef249 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 4 Jun 2026 11:17:42 +0200 Subject: [PATCH 11/17] re-generate content & fix formatting --- docs/http/http-spans.md | 36 ++++++++++++++++++++++++++++---- docs/registry/attributes/http.md | 18 ++++++++++++++-- model/http/registry.yaml | 15 ++++++++----- 3 files changed, 58 insertions(+), 11 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index ead12a13ce..4a2b8ffd78 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -276,12 +276,17 @@ If the request has completed successfully, instrumentations SHOULD NOT set `erro **[10] `network.protocol.version`:** If protocol version is subject to negotiation (for example using [ALPN](https://www.rfc-editor.org/rfc/rfc7301.html)), this attribute SHOULD be set to the negotiated version. If the actual protocol version is not known, this attribute SHOULD NOT be set. **[11] `http.request.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -Instrumentations MUST provide configuration options to control the maximum captured body size. +In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), +instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. +Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, +configuration and usage of the instrumented HTTP client and server libraries. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. @@ -303,12 +308,21 @@ Examples: 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. **[13] `http.response.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -Instrumentations MUST provide configuration options to control the maximum captured body size. +In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), +instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. +Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, +configuration and usage of the instrumented HTTP client and server libraries. + +For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP +[client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. +This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. @@ -615,12 +629,17 @@ When a query string value is redacted, the query string key SHOULD still be pres **[14] `client.port`:** When observed from the server side, and when communicating through an intermediary, `client.port` SHOULD represent the client port behind any intermediaries, for example proxies, if it's available. **[15] `http.request.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -Instrumentations MUST provide configuration options to control the maximum captured body size. +In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), +instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. +Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, +configuration and usage of the instrumented HTTP client and server libraries. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. @@ -642,12 +661,21 @@ Examples: 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. **[17] `http.response.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -Instrumentations MUST provide configuration options to control the maximum captured body size. +In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), +instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. +Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, +configuration and usage of the instrumented HTTP client and server libraries. + +For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP +[client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. +This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 2655350b7f..b2740ccb40 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -30,12 +30,17 @@ This document defines semantic convention attributes in the HTTP namespace. | `http.route` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | 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 MUST be limited in size and thus value is expected to be truncated in many cases. -Instrumentations MUST provide configuration options to control the maximum captured body size. +In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), +instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. +Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, +configuration and usage of the instrumented HTTP client and server libraries. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. @@ -82,12 +87,21 @@ Tracing instrumentations that do so, MUST also set `http.request.method_original **[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 MUST be limited in size and thus value is expected to be truncated in many cases. -Instrumentations MUST provide configuration options to control the maximum captured body size. +In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), +instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. +Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, +configuration and usage of the instrumented HTTP client and server libraries. + +For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP +[client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. +This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. + Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. diff --git a/model/http/registry.yaml b/model/http/registry.yaml index 216d330fc6..51c419c5cb 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -210,14 +210,16 @@ groups: The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. - In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), + In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the + [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. - Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, configuration and usage of the instrumented HTTP client and server libraries. + Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, + configuration and usage of the instrumented HTTP client and server libraries. Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. @@ -229,16 +231,19 @@ groups: The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. note: | Captured value MUST be limited in size and thus value is expected to be truncated in many cases. - In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), + In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the + [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. - Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, configuration and usage of the instrumented HTTP client and server libraries. + Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, + configuration and usage of the instrumented HTTP client and server libraries. - For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP [client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. + For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP + [client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics From a39747cdc84c99131eee16ef043bdb1c680b46ed Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Tue, 23 Jun 2026 09:55:15 +0200 Subject: [PATCH 12/17] simplify max captured body size --- docs/http/http-spans.md | 40 +++++++++++++++++++------------- docs/registry/attributes/http.md | 20 +++++++++------- model/http/registry.yaml | 20 +++++++++------- 3 files changed, 48 insertions(+), 32 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index 48385e797a..d7ef7f6d04 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -276,10 +276,12 @@ If the request has completed successfully, instrumentations SHOULD NOT set `erro **[10] `network.protocol.version`:** If protocol version is subject to negotiation (for example using [ALPN](https://www.rfc-editor.org/rfc/rfc7301.html)), this attribute SHOULD be set to the negotiated version. If the actual protocol version is not known, this attribute SHOULD NOT be set. -**[11] `http.request.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), -instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. +**[11] `http.request.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + +The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + +To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. @@ -308,10 +310,12 @@ Examples: - 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. -**[13] `http.response.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), -instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. +**[13] `http.response.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + +The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + +To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. @@ -630,10 +634,12 @@ When a query string value is redacted, the query string key SHOULD still be pres **[14] `client.port`:** When observed from the server side, and when communicating through an intermediary, `client.port` SHOULD represent the client port behind any intermediaries, for example proxies, if it's available. -**[15] `http.request.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), -instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. +**[15] `http.request.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + +The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + +To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. @@ -662,10 +668,12 @@ Examples: - 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. -**[17] `http.response.body.content`:** Captured value MUST be limited in size and thus value is expected to be truncated in many cases. -In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), -instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. +**[17] `http.response.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + +The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + +To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index b2740ccb40..4e6dff66ba 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -29,10 +29,12 @@ This document defines semantic convention attributes in the HTTP namespace. | `http.response.status_code` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | int | [HTTP response status code](https://tools.ietf.org/html/rfc7231#section-6). | `200` | | `http.route` | ![Stable](https://img.shields.io/badge/-stable-lightgreen) | 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 MUST be limited in size and thus value is expected to be truncated in many cases. -In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), -instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. +**[1] `http.request.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + +The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + +To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. @@ -86,10 +88,12 @@ Tracing instrumentations that do so, MUST also set `http.request.method_original **[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 MUST be limited in size and thus value is expected to be truncated in many cases. -In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), -instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. +**[5] `http.response.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + +The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the +[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + +To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. diff --git a/model/http/registry.yaml b/model/http/registry.yaml index 51c419c5cb..f70bf19a4f 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -209,10 +209,12 @@ groups: brief: > The content of the uncompressed HTTP request body, captured as a string when the request content is textual or as binary otherwise. note: | - Captured value MUST be limited in size and thus value is expected to be truncated in many cases. - In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the - [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), - instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. + Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + + The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the + [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + + To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. @@ -230,10 +232,12 @@ groups: brief: > The content of the uncompressed HTTP response body, captured as a string when the response content is textual or as byte array otherwise. note: | - Captured value MUST be limited in size and thus value is expected to be truncated in many cases. - In addition to respecting the `AttributeValueLengthLimit` configuration option defined in the - [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters), - instrumentations SHOULD provide configuration options or arbitrary limits to further limit the captured body size. + Captured value MAY be limited in size and thus value is expected to be truncated in many cases. + + The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the + [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). + + To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. From 5f12bf5301f0fa81957ef12f9f29d7c005f6a5f8 Mon Sep 17 00:00:00 2001 From: SylvainJuge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 2 Jul 2026 10:00:11 +0200 Subject: [PATCH 13/17] Apply suggestion from @lmolkova Co-authored-by: Liudmila Molkova --- docs/registry/attributes/http.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 4e6dff66ba..36bb36cba9 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -36,7 +36,10 @@ The maximum captured body size must be limited by the `AttributeValueLengthLimit To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. -Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. +Instrumentations MUST NOT capture this attribute by default and MAY provide an option to enable it. + +> [!WARNING] +> This attribute may contain sensitive information. Instrumentations 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. From 332ffef5cd28c31f5710cf6445089ed40a1185e2 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 2 Jul 2026 10:37:48 +0200 Subject: [PATCH 14/17] post-review changes --- docs/http/http-spans.md | 36 ++++++++++++++------------------ docs/registry/attributes/http.md | 23 ++++++++------------ model/http/registry.yaml | 18 +++++++--------- 3 files changed, 33 insertions(+), 44 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index d7ef7f6d04..559a1b0af0 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -287,12 +287,13 @@ Instrumentations MUST disable capture by default and provide an opt-in configura Instrumentations 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. -Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, -configuration and usage of the instrumented HTTP client and server libraries. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. + **[12] `http.request.header.`:** 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. @@ -321,16 +322,13 @@ Instrumentations MUST disable capture by default and provide an opt-in configura Instrumentations 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. -Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, -configuration and usage of the instrumented HTTP client and server libraries. - -For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP -[client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. -This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. + **[14] `http.response.header.`:** 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. @@ -645,12 +643,13 @@ Instrumentations MUST disable capture by default and provide an opt-in configura Instrumentations 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. -Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, -configuration and usage of the instrumented HTTP client and server libraries. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. + **[16] `http.request.header.`:** 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. @@ -679,16 +678,13 @@ Instrumentations MUST disable capture by default and provide an opt-in configura Instrumentations 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. -Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, -configuration and usage of the instrumented HTTP client and server libraries. - -For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP -[client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. -This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. + **[18] `http.response.header.`:** 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. diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 36bb36cba9..2458a48582 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -36,19 +36,17 @@ The maximum captured body size must be limited by the `AttributeValueLengthLimit To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. -Instrumentations MUST NOT capture this attribute by default and MAY provide an option to enable it. - -> [!WARNING] -> This attribute may contain sensitive information. +Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. -Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, -configuration and usage of the instrumented HTTP client and server libraries. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. + **[2] `http.request.header.`:** 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. @@ -102,16 +100,13 @@ Instrumentations MUST disable capture by default and provide an opt-in configura Instrumentations 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. -Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, -configuration and usage of the instrumented HTTP client and server libraries. - -For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP -[client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. -This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. + **[6] `http.response.header.`:** 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. diff --git a/model/http/registry.yaml b/model/http/registry.yaml index f70bf19a4f..f5eaf4b5c6 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -220,11 +220,12 @@ groups: Instrumentations 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. - Capturing HTTP request body content should be considered as fragile by nature as it depends on implementation details, - configuration and usage of the instrumented HTTP client and server libraries. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + + 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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] stability: development - id: http.response.body.content @@ -243,14 +244,11 @@ groups: Instrumentations 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. - Capturing HTTP response body content should be considered as fragile by nature as it depends on implementation details, - configuration and usage of the instrumented HTTP client and server libraries. - - For HTTP clients, the [HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/) define the HTTP - [client span duration](https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span-duration) to end when the response headers are received. - This means that the HTTP response body is typically read after the span has ended and thus can't be easily captured as a span attribute. - Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. + + 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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] stability: development From 93e0f5dafb44bb8459bf04062a9d0eaedb0dbe58 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 2 Jul 2026 10:44:39 +0200 Subject: [PATCH 15/17] fix yamllint --- model/http/registry.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/model/http/registry.yaml b/model/http/registry.yaml index f5eaf4b5c6..3f043f7e3a 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -223,7 +223,8 @@ groups: Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. - 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. + 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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] @@ -247,7 +248,8 @@ groups: Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. - 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. + 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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. examples: ['Hello world!', '{"foo: "bar"}', 'aGVsbG8='] From ec37ec1d448bce544bd0ea4b0993f2077e802c1e Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Thu, 2 Jul 2026 10:48:37 +0200 Subject: [PATCH 16/17] try to fix things --- docs/http/http-spans.md | 12 ++++++++---- docs/registry/attributes/http.md | 6 ++++-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index 559a1b0af0..2fef3ed10a 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -290,7 +290,8 @@ Instrumentations SHOULD capture the body as string whenever possible as it makes Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -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. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. @@ -325,7 +326,8 @@ Instrumentations SHOULD capture the body as string whenever possible as it makes Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -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. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. @@ -646,7 +648,8 @@ Instrumentations SHOULD capture the body as string whenever possible as it makes Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -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. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. @@ -681,7 +684,8 @@ Instrumentations SHOULD capture the body as string whenever possible as it makes Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -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. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 2458a48582..9a041945f7 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -43,7 +43,8 @@ Instrumentations SHOULD capture the body as string whenever possible as it makes Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -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. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. @@ -103,7 +104,8 @@ Instrumentations SHOULD capture the body as string whenever possible as it makes Textual content is typically detected based on the [Content-Type](https://www.rfc-editor.org/rfc/rfc9110.html#field.content-type) header using heuristics such as checking if the media type starts with `text/` or ends with `/json`, `+json`, `/xml`, `+xml`, `/yaml` or `+yaml` or if the media type contains an explicit charset with `;charset=`. -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. +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 on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. From 7d5fedf1f409ed5e9f971176f6c247d67cb86668 Mon Sep 17 00:00:00 2001 From: Sylvain Juge <763082+SylvainJuge@users.noreply.github.com> Date: Fri, 10 Jul 2026 15:13:02 +0200 Subject: [PATCH 17/17] remove few paragraphs --- docs/http/http-spans.md | 20 -------------------- docs/registry/attributes/http.md | 10 ---------- model/http/registry.yaml | 10 ---------- 3 files changed, 40 deletions(-) diff --git a/docs/http/http-spans.md b/docs/http/http-spans.md index 199693d0ce..7750006694 100644 --- a/docs/http/http-spans.md +++ b/docs/http/http-spans.md @@ -278,11 +278,6 @@ If the request has completed successfully, instrumentations SHOULD NOT set `erro **[11] `http.request.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. -The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - -To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. @@ -314,11 +309,6 @@ Examples: **[13] `http.response.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. -The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - -To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. @@ -636,11 +626,6 @@ When a query string value is redacted, the query string key SHOULD still be pres **[15] `http.request.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. -The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - -To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. @@ -672,11 +657,6 @@ Examples: **[17] `http.response.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. -The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - -To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. diff --git a/docs/registry/attributes/http.md b/docs/registry/attributes/http.md index 9a041945f7..858c5316d5 100644 --- a/docs/registry/attributes/http.md +++ b/docs/registry/attributes/http.md @@ -31,11 +31,6 @@ This document defines semantic convention attributes in the HTTP namespace. **[1] `http.request.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. -The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - -To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. @@ -92,11 +87,6 @@ Tracing instrumentations that do so, MUST also set `http.request.method_original **[5] `http.response.body.content`:** Captured value MAY be limited in size and thus value is expected to be truncated in many cases. -The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the -[OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - -To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. diff --git a/model/http/registry.yaml b/model/http/registry.yaml index 3f043f7e3a..8aa552b801 100644 --- a/model/http/registry.yaml +++ b/model/http/registry.yaml @@ -211,11 +211,6 @@ groups: note: | Captured value MAY be limited in size and thus value is expected to be truncated in many cases. - The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the - [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - - To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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. @@ -236,11 +231,6 @@ groups: note: | Captured value MAY be limited in size and thus value is expected to be truncated in many cases. - The maximum captured body size must be limited by the `AttributeValueLengthLimit` configuration option defined in the - [OpenTelemetry SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#configurable-parameters). - - To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. - Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. Instrumentations 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.