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
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 open-telemetry/semantic-conventions#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:
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 open-telemetry/semantic-conventions#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:The text was updated successfully, but these errors were encountered: