With #103769, we are now redacting away the entire query component from Uri-s in .NET 9. This brings .NET behavior closer to what we can call secure by default, however, it's problematic for users who (1) need to include safe query values in their telemetry (2) need to filter out more, eg. some parts of Path. Ideally, there should be a fine-grained customization mechanism that allows to redact just certain parts of the url (eg. given query entries or parts of the path) or to leave the Uri value as-is.
Note that unlike initially assumed in #93221, we don't see a mandatory 1:1 relationship between a redacted url.full and the url.template, since the primary purpose of the latter is to have a low-cardinality attribute identifying the destination endpoint, see https://github.com/open-telemetry/semantic-conventions/issues/1095. Regardless, we acknowledge that some users may want to (re)use the template in order extract the filtered url value.
As a result, the solution should enable users to extract the template when defining their Uri filters. Assuming that the template will be attached to the HttpRequestMessage in some form, a potential solution could be a per-handler filtering delegate that takes the request:
public class (SocketsHttp|HttpClient)Handler
{
public Func<HttpRequestMessage, string>? UriRedactionFilter { get; set; }
}
With #103769, we are now redacting away the entire query component from Uri-s in .NET 9. This brings .NET behavior closer to what we can call secure by default, however, it's problematic for users who (1) need to include safe query values in their telemetry (2) need to filter out more, eg. some parts of Path. Ideally, there should be a fine-grained customization mechanism that allows to redact just certain parts of the url (eg. given query entries or parts of the path) or to leave the Uri value as-is.
Note that unlike initially assumed in #93221, we don't see a mandatory 1:1 relationship between a redacted
url.full
and theurl.template
, since the primary purpose of the latter is to have a low-cardinality attribute identifying the destination endpoint, see https://github.com/open-telemetry/semantic-conventions/issues/1095. Regardless, we acknowledge that some users may want to (re)use the template in order extract the filtered url value.As a result, the solution should enable users to extract the template when defining their Uri filters. Assuming that the template will be attached to the
HttpRequestMessage
in some form, a potential solution could be a per-handler filtering delegate that takes the request: