You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The HTTP Logging Transport introduced in #1006 (and documented in #1011) is a great addition. However, the field names are not consistent.
For example, for certain request fields, the log field has a name in the format tf_http_<field>, such as the requested URI is tf_http_req_uri, and the HTTP method is tf_http_req_method. However, most header fields are added as-is to the log fields, for example Accept-Encoding and User-Agent.
This would use http.method for the request method and http.url for the requested URI. Headers are added using a consistent format: http.[request|response].header.<key>, where <key> is the normalized header name, in lower case, with - replaced with _. For example, Accept-Encoding would be http.request.header.accept_encoding.
The text was updated successfully, but these errors were encountered:
The HTTP Logging Transport introduced in #1006 (and documented in #1011) is a great addition. However, the field names are not consistent.
For example, for certain request fields, the log field has a name in the format
tf_http_<field>
, such as the requested URI istf_http_req_uri
, and the HTTP method istf_http_req_method
. However, most header fields are added as-is to the log fields, for exampleAccept-Encoding
andUser-Agent
.I propose using consistent log field naming, for example based on the Semantic Conventions from OpenTelemetry.
This would use
http.method
for the request method andhttp.url
for the requested URI. Headers are added using a consistent format:http.[request|response].header.<key>
, where<key>
is the normalized header name, in lower case, with-
replaced with_
. For example,Accept-Encoding
would behttp.request.header.accept_encoding
.The text was updated successfully, but these errors were encountered: