Use of [ and ] in premium RSS feed for bombcast problematic

Hi, folks. I'm trying to use the premium RSS feed for the bombcast with my podcatching software, DoggCatcher for Android.

Unfortunately, it does not accept the [ and ] characters as being valid in the path portion of a URL. From a quick Googling, it appears that those characters are actually not intended to be used in the path of a URL.

See: Stack Overflow - Which Characters Make a URL Invalid?

I've sent this same link to the authors of DoggCatcher for their attention, but it may be quicker for you guys to solve this problem going forward.

Thanks,

Jon

--

It turns out that the problem is that you guys are including [ and ] directly in the URL string. In order for the URL to be valid, [ must be encoded as %5B, and ] must be encoded as %5D. If you look at the premium podcast feed's html page, you'll see folks with a few different podcatchers reporting failures on the premium feed as well. - Jon

From the above, it appears that the [ character would be legal if rendered as %5B, and ] would be if rendered as %5D.

As you are including these characters directly in the feed URL, you're generating an invalid URL according to the Stack Overflow discussion, so it would be best if you could fix this on your end.

Brackets are technically valid in a URL. I saw a screenshot of DoggCatcher in another thread, and it looks like there was a java illegal character error. I think the author of the app needs to escape/encode the brackets or quote the URL string, so I don't think the error is on GiantBomb's side.

If you read the above Stack Overflow link, they provide pretty conclusive RFC citations that it's Giant Bomb's problem. From reading the premium podcast RSS page, there are other bombers using different podcatching software that are reporting problems as well, so I really do think the problem is on Giant Bomb's side.

Are you sureyou're using the correct RSS feed?

It looks like they're in the process of fixing the problem. The mp3 link on the premium 25 March 2014 bombcast page is properly encoded now, though the RSS feed is not quite there yet.

I'm using the RSS feed linked off of http://www.giantbomb.com/podcasts/premium/, so yeah, I'm pretty sure. Right now, that RSS feed is just stripping out the [ and ] characters, rather than doing %5B and %5D encoding of them, and when I use Chrome to try to pull down those URLs, I just get bounced back to the same page.

As I say, the mp3 link is properly encoded.

Edit: It looks like the <link> element in each <item> element is pointing to the page for each podcast rather than the mp3 file. The <enclosure> element is properly encoded, but neither Chrome's RSS reader nor DoggCatcher seems to be using that one.

Edit: Unless GiantBomb has just changed their RSS feed, it looks like it is DoggCatcher's problem after all, given proper encoding in the <enclosure> element. I've relayed all of this to DoggCatcher for their response.

The RFC says brackets are reserved, so they should be escaped... and it looks like the URLs in the feed are actually encoded, it's just the browser is decoding them for you when you're looking at the page. If you look at the source, you'll see:

<a href="http://www.giantbomb.com/podcasts/download/810/Giant_Bombcast_03_25_2014_%5BPremium%5D-03-25-2014-4153733564.mp3"></a>

I don't know how DoggCatcher is parsing the XML, but it seems valid. I might be wrong.

@gaff: Yeah, you're right, I wasn't examining the RSS feed myself. It is encoding the [ and ] properly, it's DoggCatcher that is getting confused by them during their processing. It looks like they extract the download URL, decode it at that point, and then attempt to use it without re-encoding it later on.

GiantBomb could around the problem by not using the [ and ] characters, but they appear to be doing everything right. Sorry about the confusion.