HttpClientLogger doesn't log query string parameters

[darraghjones]

I raised this github issue #6385 and it seems like it's been completed by this PR #6521.

but if i understand correctly, the way it's implemented, i need to opt-in for each query string key/value pair i want to log?

i don't really understand that design decision. it seems like it's got something to do with redacting potentially sensitive information in the query string?

but the logger already lets you log the entire request/response body.

i really want to use this logger, because logging the request/body has always been challenging in asp.net. but it seems like logging the simple things like headers and query string, this logger makes difficult.

where is the "just log everything" option?

[darraghjones]

@rainsxng are you able to share some insight?

[rainsxng]

@darraghjones your understanding is correct, you have to opt-in each query string key for it to be logged. There are multiple justifications for that:

1. Query string parameters frequently carry PII information ( tokens, emails, ids). That allow list forces to deliberately pick what parameters to log and what not, since the cost of accidentally logging sensitive data is usually higher than the cost of adding configuration for non-sensitive keys.
2. Collecting each key/value pair increases tag cardinality and would make aggregation expensive, while allow list keeps dimensions stable.

Query parameters logging follows the same approach as we have it for headers and path segments since they are small, enumerable, can carry sensitive tokens or IDs, and become structured tags that impact telemetry size and cost. Bodies are only logged when explicitly enabled and content types are allow‑listed; parsing and redacting arbitrary body payloads would add significant overhead, so we keep body handling coarse and let applications add custom enrichers if field redaction is needed.

It is possible to add an option to log all the parameters, but I don't see enough justification for that yet.

cc @evgenyfedorov2 @dariusclay

[darraghjones]

I appreciate you taking the time to come back to me. i'm not sure i agree with the cardinality argument. if you have a query string like "name" the values could be almost endless.

[darraghjones]

unless, the suggestion is to only allow query string parameters where the possible values is known to be limited?

[rainsxng]

The intent is not only allow keys with a small value set, but for each key decide: log unredacted (bounded/operational), redact (collapse all values to one token), or skip. So the allow-list drives deliberate per‑key treatment; it doesn’t require the value domain to be small, it just lets you control how high‑entropy keys affect telemetry and privacy.