Potential issue: len(Headers) counts duplicate entries, disagreeing with keys()/iteration

[Sun-Wukhan]

Found while property-based testing the models.

h = httpx.Headers([("a", "1"), ("a", "2")])
len(h)          # 2
list(h)         # ["a"]
list(h.keys())  # ["a"]
dict(h)         # {"a": "1, 2"}

Headers presents a Mapping interface, and its keys()/iter deduplicate — but len returns len(self._list), the raw entry count, so len() disagrees with the number of keys the mapping reports. For a plain dict those always agree, and code doing len(headers) to count distinct header names gets a surprising answer when duplicates are present (which is normal for real HTTP traffic, e.g. multiple Set-Cookie... in a Headers instance built from a raw list).

Is the entry-count semantics deliberate (multidict-style) or an oversight? If it should count distinct keys, the fix is one line — len of the keys view — and I can prepare it on a fork branch. Raising it here first since it is a visible behaviour change either way, and PR creation on this repo is limited to collaborators.

[0xamlab]

len(h) currently counts raw entries, not distinct names. On HTTPX 0.28.1 and master b5addb6, Headers([("a","1"),("a","2")]) gives len(h)==2, list(h)==["a"], and len(h.raw)==2.

__len__ returns raw storage length at httpx/_models.py:353-354, while keys() deduplicates at lines 202-203. Since Headers subclasses MutableMapping (line 139), this is a real Mapping-contract inconsistency. Use len(h.keys()) for distinct names or len(h.multi_items()) for entries. Changing __len__ to len(self.keys()) would align the interface, but would break existing entry-count behavior.