Commits on Source (5)
-
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. (cherry picked from commit 5d5ccbc0)
9b4bd076 -
Switching to std::string simplifies the next patch changing the URL scheme. (cherry picked from commit bc1d58c0)
a5e97d74 -
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. (cherry picked from commit 44de051a)
237ab100 -
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 (cherry picked from commit 241fed31)
0229706f