Disabling/filtering query parameters for URIs in HTTP tracing

[CarnaViire]

Similar to #68675, we should consider some kind of configuration for disabling/filtering query parameters for URIs in HTTP tracing.

We should also discuss whether it should be a single config for tracing and logging, or they should be different.

Last time we discussed it, we believed it will be better to keep them separate for discoverability -- configuring HttpClientFactory's logging would make more sense as a part of general HttpClientFactory configuration.

Consuming tracing requires more conscious effort, so a setting there might be less evident (e.g. AppContext switch).

We also discussed that we generally don't like messing with all Uris at once (e.g. setting that will apply globally to all Uri.ToString)

Note that Barry's opinion was to have a single setting:

It’s difficult, because I can see folks taking trace events and saving them for debugging or security parsing. And once that happens it’s exactly the same problem. I’d say match the two.

So I wonder maybe tracing's setting can apply to logging, but not the other way around.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Similar to #68675, we should consider some kind of configuration for disabling/filtering query parameters for URIs in HTTP tracing.

We should also discuss whether it should be a single config for tracing and logging, or they should be different.

Last time we discussed it, we believed it will be better to keep them separate for discoverability -- configuring HttpClientFactory's logging would make more sense as a part of general HttpClientFactory configuration.

Consuming tracing requires more conscious effort, so a setting there might be less evident (e.g. AppContext switch).

We also discussed that we generally don't like messing with all Uris at once (e.g. setting that will apply globally to all Uri.ToString)

Note that Barry's opinion was to have a single setting:

It’s difficult, because I can see folks taking trace events and saving them for debugging or security parsing. And once that happens it’s exactly the same problem. I’d say match the two.

So I wonder maybe tracing's setting can apply to logging, but not the other way around.

Author:	CarnaViire
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[MihaZupan]

Just to confirm, are we are only concerned about the pathAndQuery parameter of the RequestStart event for System.Net.Http?

If we were to consider the path as well, we should work with ASP.NET as they also have tracing that includes such info (e.g. KestrelEventSource.RequestStart).

[karelz]

Triage: Would be nice to get it in 8.0 as it makes security easier for specific set of users.