Fix parsing patterns for SSDP responses in Sonos #1108
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dljsjr
requested review from
greens,
varzac,
tandres,
FreeMasen,
elbe0046,
cjswedes and
NoahCornell
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 7e4e948 |
|
Channel deleted. |
varzac
reviewed
Dec 9, 2023
tandres
approved these changes
Dec 11, 2023
|
|
dljsjr
force-pushed
the
fix/sonos-discovery-non-ascii-name-failure
branch
from
051dfdb to
33e863f
Compare
The current way we parse the SSDP response headers can cause failures in discovering Sonos speakers with unicode characters that require more than one byte for their representation, such as CJK characters. The current parsing patterns use the '`%g`' character class, which does not parse characters that don't fit in a single byte; while Lua itself is utf-8 compatible and it is safe to use multi-code-point graphemes or clusters in Lua strings, the actual string library is byte-oriented for many operations and the pattern used currently tries to match each byte against the provided class. '`.-`' works here instead, as it matches all bytes in a non-greedy way (akin to '`.*?`' in PCRE).
dljsjr
force-pushed
the
fix/sonos-discovery-non-ascii-name-failure
branch
from
bab287d to
570b8af
Compare
dljsjr
force-pushed
the
fix/sonos-discovery-non-ascii-name-failure
branch
from
570b8af to
4e19c74
Compare
varzac
reviewed
Dec 12, 2023
cjswedes
approved these changes
Dec 12, 2023
Previous approach could have potentially accepted invalid headers. This tweaks the parsing pattern to fail to find headers that don't coform to the actual accepted structure of a header key.
dljsjr
force-pushed
the
fix/sonos-discovery-non-ascii-name-failure
branch
from
4e19c74 to
7e4e948
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current way we parse the SSDP response headers can cause failures in discovering Sonos speakers with Unicode characters that require more than one byte for their representation, such as CJK characters.
The current parsing patterns use the '
%g' character class, which does not match characters that don't fit in a single byte. While Lua itself is utf-8 compatible, and it is safe to use multi-code-point graphemes or clusters in Lua strings, the actual string library is byte-oriented for many operations. The pattern used currently tries to match each byte against the provided class, which causes it to fail to match and capture many headers.We now use a parsing pass for header key/value pairs derived from the Luncheon library with bug fixes that is aware of the proper structure for HTTP Header key/values, which is the format that an SSDP response uses.