Better handling behind portals
@hadess
Submitted by Bastien Nocera Assigned to gri..@..e.bugs
Link to original bug (#769826)
Description
In some cases, when behind flaky captive portals, the network might be "available" in GNetworkMonitor, but the HTTP calls would throw:
$ wget -Ofoo "http://thegamesdb.net/api/GetGamesList.php?name=Strider&platform=Sega%20Genesis"
--2016-08-13 14:22:18-- http://thegamesdb.net/api/GetGamesList.php?name=Strider&platform=Sega%20Genesis
Resolving thegamesdb.net (thegamesdb.net)... 104.27.146.170, 104.27.147.170, 2400:cb00:2048:1::681b:93aa, ...
Connecting to thegamesdb.net (thegamesdb.net)|104.27.146.170|:80... connected.
HTTP request sent, awaiting response... 302 Hotspot login required
Location: https://captive-portal.scc.kit.edu/login?dst=http%3A%2F%2Fthegamesdb.net%2Fapi%2FGetGamesList.php%3Fname%3DStrider%26platform%3DSega%2520Genesis [following]
--2016-08-13 14:22:18-- https://captive-portal.scc.kit.edu/login?dst=http%3A%2F%2Fthegamesdb.net%2Fapi%2FGetGamesList.php%3Fname%3DStrider%26platform%3DSega%2520Genesis
Resolving captive-portal.scc.kit.edu (captive-portal.scc.kit.edu)... 129.13.64.129
Connecting to captive-portal.scc.kit.edu (captive-portal.scc.kit.edu)|129.13.64.129|:443... connected.
HTTP request sent, awaiting response... 200 OK
First, we probably need to change the API used in GrlNet to actually care about HTTP statuses, and not just follow redirects and feed captive portals to grilo plugins.
The second part is that it might be nice to detect captive portals and propagate that state to the registry, so we hide sources that are not available.
Edited by Victor Toso