Adblock Plus breaking Blubrry Podcast Redirect URLs
Posted: Sat Dec 24, 2016 4:29 am
I have Adblock Plus for Android 1.3 build 139, with EasyList subscribed.
I'm trying to listen to a podcast in AntennaPod, where all the URLs to the episodes look like this:
Basically, the URLs have additional, unescaped URLs in them, and the blubrry server responds with a redirect to whatever it gets after chopping the prefix off. If I try to escape the second, contained URL (so using ), I get redirected to the still-escaped URL and it doesn't work.
I can wget that URL on my computer, and on my phone with ABP's filtering turned off:
But when ABP has filtering turned off, I get a 404 error on the URL (presumably from the proxy that ABP is running everything through):
I think that whatever the proxy is using to figure out what URL to go fetch is getting badly confused by these URLs.
Is there a way to work around this by changing the proxy's configuration somehow? Can the proxy be fixed to handle these not-quite-standard-obeying-but-in-production-use URLs?
I'm trying to listen to a podcast in AntennaPod, where all the URLs to the episodes look like this:
Code: Select all
http://media.blubrry.com/smasheverything/http://feeds.soundcloud.com/stream/259464060-smash-everything-podcast-last-names.mp3
Code: Select all
http://media.blubrry.com/smasheverything/http%3A%2F%2Ffeeds.soundcloud.com%2Fstream%2F259464060-smash-everything-podcast-last-names.mp3
I can wget that URL on my computer, and on my phone with ABP's filtering turned off:
Code: Select all
Connecting to media.blubrry.com (54.87.43.77:80)
Connecting to feeds.soundcloud.com (72.21.91.127:80)
Connecting to feeds-tmp.soundcloud.com (72.21.91.127:80)
Connecting to ec-media.sndcdn.com (72.21.81.77:80)
259464060-smash-ever 100% |*******************************| 26409k 0:00:00 ETA
Code: Select all
Connecting to media.blubrry.com (54.87.43.77:80)
wget: server returned error: HTTP/1.1 404 Not Found
Is there a way to work around this by changing the proxy's configuration somehow? Can the proxy be fixed to handle these not-quite-standard-obeying-but-in-production-use URLs?