When a user supplies an explicit data_collection config, _filter_headers routes header scrubbing through _apply_key_value_collection_filtering. If http_headers.request is omitted, _http_headers_from_value resolves it to {"mode": "denylist"} with no extra terms, so only the built-in _SENSITIVE_DENYLIST applies. That denylist contains none of the terms needed to match x-forwarded-for or x-real-ip, so those IP-address headers (PII) pass through unfiltered. This is a regression relative to the send_default_pii-derived mapping (_map_from_send_default_pii), which — when PII is off — explicitly adds the terms ["forwarded", "-ip", "remote-", "via", "-user"] and the legacy SENSITIVE_HEADERS path which scrubs X_FORWARDED_FOR and X_REAL_IP. A user who enables data_collection for an unrelated purpose (e.g. cookies) inadvertently starts sending client IP headers that were previously scrubbed.

_get_request_attributes in _asgi_common.py gates http.query, url.path, url.full, and client.address behind should_send_default_pii(). That helper reads only the raw send_default_pii option and returns False when a user configures data_collection alone (without send_default_pii). Because this branch routes only HTTP header filtering through data_collection while these URL/query/client attributes still key off send_default_pii, a user who adopts data_collection as a replacement for send_default_pii will silently lose these OTel span attributes even though their data_collection config (e.g. query_params defaults to collect) implies they should be captured. The two new tests mask this gap by passing send_default_pii=True alongside data_collection, which also emits an unasserted DeprecationWarning from _resolve_data_collection. This is dropped telemetry (fail-safe direction), not over-collection, and likely reflects an incomplete migration, so severity is low.