upnp: fix exposed directory URLS
- May 28, 2024
-
-
Previous implementation generated input item directories with URLs not compliant with *RFC 3986* in an attempt to keep the original URL while triggering the UPNP directory acces properly. Here's an exemple of a previous upnp directory url: > upnp://http://192.168.1.109:32469/cds?ObjectID=0 The stacking of schemes (`upnp://http://`) is problematic and leads to most of the validators failing on those generated URLs (see the referenced issue). This patch fix the issue by simply replacing the original `http://` scheme by `upnp://` instead of stacking both. To avoid any potential regression with some obscure usage forcing https, a shortcut of the directory access is introduced for https specificaly. The example above would then be fixed like that: > upnp://192.168.1.109:32469/cds?ObjectID=0 Potential use-cases with https would instead generate the following: > upnps://192.168.1.109:32469/cds?ObjectID=0 Refs VLCKit#728
241fed31 -
In preparation for the next commit, explicitly refuse any protocols that are not supported by libpupnp. It's unclear if it's needed and pupnp probably already perform this check, but the next commit rely heavily on the scheme matching "http" or "https" only.
44de051a -
Switching to std::string simplifies the next patch changing the URL scheme.
bc1d58c0 -
This patch completes ac99cee9. It avoids corrupting URLs with an already present query list.
0cba1475 -
Object ID is not supposed to be URI-encoded by default and can be pretty much any valid string. Since we add it to a valid encoded URL, we need to encode it to preserve the URL validity.
5d5ccbc0
-
