GNOME Bugzilla – Bug 321991
Not handling 302 redirects
Last modified: 2006-08-08 12:33:25 UTC
Distribution/Version: Fedora Core Rawhide This week in Tech uses a tracker in its RSS feeds, so it's MP3s are URLs like this: http://www.podtrac.com/pts/redirect.mp3?http://aolradio.podcast.aol.com/twit/TWiT0031H.mp3 Rhythmbox fails on this URL. Podcast RSS is: http://leo.am/podcasts/twit
The way to do this would be to use libsoup, rather than gnome-vfs, as libsoup deals with re-directs and other things. It would also let us handle permanently moved and others as well.
(This is Debian bug http://bugs.debian.org/350802.)
*** Bug 329786 has been marked as a duplicate of this bug. ***
*** Bug 335279 has been marked as a duplicate of this bug. ***
(valid bug rant ahead) yes, this bug exists. i myself was trying to figure out why random podcasts @ http://leoville.tv/podcasts/sn.xml wern't working, then i noticed the variation in the urls. only the ones with redirect urls fail to work.
*** Bug 338569 has been marked as a duplicate of this bug. ***
*** Bug 339982 has been marked as a duplicate of this bug. ***
I reported this bug to the Ubuntu bug tracker at https://launchpad.net/bugs/46799 As indicated there, this particular problem is not because of a 302 Redirect but rather the conversion of the double-slash in the URL to a single-slash, which causes the server to return a 404 Not Found. Of course, once this problem is sorted out, the redirection MAY cause trouble, but that's not the case now.
The issues with double slashes being converted into a single slash is bug 342248. Regarding redirects, we can probably handle them by doing something with gnome_vfs_module_callback_push() and GNOME_VFS_MODULE_CALLBACK_HTTP_RECEIVED_HEADERS to detect redirects. Using that looks fairly complicated though.
James, there's an example in the gnomevfssrc GStreamer plugin (it uses it to grab icecast metadata).
I've just played with it, and none of the callbacks get given the response code. I guess our options are a) get gnome-vfs to follow re-directs, b) get gnome-vfs to have a callback with the response code, or c) don't use gnome-vfs.
So, seeing your latest comment Doc, does it seem like switching to libsoup is going to be the best way to do this? I'm hitting this more and more these days and would really like to get this working. I'll even make an attempt at coding, just need to know the best direction to go in.
Created attachment 68474 [details] [review] Patch to the url parser to handle redirecting (not the right solution)
This patch is not the right solution (fixing gnome-vfs or switching to another library probably is), but I needed my EscapePod fix right now. Please note that most of the problem urls seem to be podtrac.com which means that by applying this patch you may be affecting your content provider's revenue stream.
*** Bug 347653 has been marked as a duplicate of this bug. ***
Created attachment 70171 [details] [review] slightly less evil patch This hides the query string from gnome_vfs_uri_new (so it doesn't collapse the double slash in 'http://'), then reattaches it later. This only really works well in combination with the patch on bug 330766.
If I am understanding what you are doing, you are just taking the second URL if there are two, correct? I have seen some stuff which does REAL 302 redirects (aka, one URL that the web server actual does a 302 to a different location), so this wouldn't fix this for those types.
No, that's what the first patch was doing. My patch takes a URI like http://www.podtrac.com/pts/redirect.mp3?http://aolradio.podcast.aol.com/twit/TWiT0031H.mp3 and separates the query string out, passing the base URI to gnome_vfs_uri_new (http://www.podtrac.com/pts/redirect.mp3 in this case), then adds the query string back on. This is just a cheap workaround for bug 322985.
Fine, but in the end: http://www.server.com/episode.mp3 that then hits a 302 and goes to http://media.server.com/show/episode.mp3 still isn't going to work :) So, still a hack and we still really need real 302 redirect handling.
No, that will work. gnome-vfs does actually handle redirects.
Doesn't work for me. Try this feed: http://feeds.feedburner.com/OTN_TechCasts
As mentioned on IRC, this feed doesn't work because the server hosting the actual files, streaming.oracle.com, doesn't respond to HTTP HEAD requests.
marking the patch obsolete, as the patch on bug 330766 includes it and doesn't crash quite so readily (bug 350345).
I've committed the patch from bug 330766, so I'm marking this fixed.