Bug: URL Parsing with spaces

[PaulG]

For some reason, I'm finding that when Beyondpod attempts to encode a URL containing spaces, it replaces the spaces with "+", rather than the standard "%20". I'm not sure if there are servers that support "+", but this behavior is causing many problems for me.

[StefanK]

Both + and %20 are used with "+" being the recommended choice (http://stackoverflow.com/questions/1...haracter-or-20)

According to the HTTP standard, URLs must be properly encoded and not contain spaces in them (e.g. they have to exist in the feed with spaces already replaced with %20). BP currently detects spaces in the URL and attempts to replace them with + but it is up to the server to recognize that and map it back to the file. Most servers do that automatically if it is part of the query, but some do not if it is part of the file path.

[PaulG]

If it's true that "+" is the preferred mechanism, then I believe I've seen a few mis-configured HTTP servers around. That said, that SO question actually says the opposite of what you're saying. When encoding form submissions with spaces in them, the "+" encoding is used, but when encoding file and folder locations on the server, you should use %20 , e.g.: https://www.example.com/Percent%20En...question+marks)

EDIT: I Guess the edits on the second answer support your position better. Personally, I think the fact that there's so much disagreement on the matter leans towards a hybrid approach like the one I detail below, especially since you know there are servers that support %20 and not +.

It also seems to me that BeyondPod is re-encoding things explicitly encoded with %20. I can send you an e-mail with an offending RSS feed - I wrote a script which generates RSS feeds from audiobook folders on my computer (so that I can easily choose the cover image, description and episode name, and so I can use the +x volume hack that's been so very valuable, but isn't available for virtual feeds). I used python's SimpleHTTPServer to serve the files temporarily while I wanted to download them, and generated QR codes to get the feed URL.

When I noticed the + vs. %20 problem, I changed the script to explicitly encode using %20 rather than just using a space, but for whatever reason, BeyondPod converted from %20 -> +. Evidently python's SimpleHTTPServer does not support "+" encoding of spaces (though it does support "%20". I ended up modifying my script to create symbolic links to temporarily solve the problem, but I believe I've seen this problem in the wild before (I never knew why, but there are a few episodes of some feeds that always showed 404s in BeyondPod, and I had to go to the website, download them, then put them in the relevant folder - I'll keep an eye out to see if it's related to the + vs %20 issue). At the very least, Beyondpod should leave %20 alone if it finds it, rather than convert it to spaces (though it's possible that for whatever reason Android converts %20 to a space, then you end up converting it back...)

One suggestion would be if there's a 404 error in a file that has spaces replaced with + signs, to give it another try encoding with %20 instead. An alternative would be to have a hidden/advanced per-feed setting to choose between + and %20, or a hybrid approach - if it detects that it works with + but not %20 or vice-versa, to have the per-feed setting automatically switch to the one that works.

[StefanK]

Paul,

BP will not re-encode the %20 - it does that only if there is a space. My guess is that there something was cached from your old feed. Just try deleting the feed and re-adding it again.

[PaulG]

Paul,

BP will not re-encode the %20 - it does that only if there is a space. My guess is that there something was cached from your old feed. Just try deleting the feed and re-adding it again.

This is possible, but I do think I did that in the testing phase. This week some time I'll try to change the script so it stops doing this symbolic linking thing and uses %20 instead of + and see if BP is re-encoding the URL for whatever reason. Either way, I think my suggestion about using one of the hybrid approaches is still relevant. Even if it's a server that's not standards compliant, most BP users won't even know what the problem is, and even if they did somehow know the problem, it seems unlikely that they'd be able to get the feed owner to change their practices (especially if the feed is some old feed that is no longer updated but still has interesting/relevant content).