fix: keep key= distinct from a valueless key in TXT records - #1813
Conversation
8edd983 to
3f555e7
Compare
|
@bluetoothbot review |
|
|
bluetoothbot
left a comment
There was a problem hiding this comment.
Tip
No blocking issues found — ready to merge.
Re-reviewed. Head unchanged at |
bluetoothbot
left a comment
There was a problem hiding this comment.
Tip
No blocking issues found — ready to merge.
5e86eb1 to
cd1f780
Compare
RFC 6763 6.4: a key with no '=' is a boolean attribute; `key=` is present with an empty value. Collapsing both to None makes them indistinguishable, so a received `key=` re-encodes as a bare `key`. Regression in #1225 (first released in 0.80.0), which replaced explicit branching on the separator with `value or None`. Restores the behaviour #226 introduced.
cd1f780 to
9f2b4ac
Compare
bluetoothbot
left a comment
There was a problem hiding this comment.
Tip
No blocking issues found — ready to merge.
## v0.150.2 (2026-08-28) ### Bug Fixes - Keep `key=` distinct from a valueless `key` in TXT records ([#1813](python-zeroconf/python-zeroconf#1813), [`899eaaa`](python-zeroconf/python-zeroconf@899eaaa)) ## v0.150.1 (2026-08-28) ### Bug Fixes - Build with cython 3.3.0 ([#1820](python-zeroconf/python-zeroconf#1820), [`df947b2`](python-zeroconf/python-zeroconf@df947b2))

RFC 6763 6.4: a key with no '=' is a boolean attribute;
key=is present with an empty value. Collapsing both to None makes them indistinguishable, so a receivedkey=re-encodes as a barekey.Regression in #1225 (first released in 0.80.0), which replaced explicit branching on the separator with
value or None. Restores the behaviour #226 introduced.