To reproduce:
1. Open Rhythmbox
2. Open menu Music > New Podcast Feed
3. Add feed "http://www.pheedo.com/e/b7f9489601ab23c2b3e3516d44e5ac9b/podcast.mp3?e_id=EF83BDDD-E77B-CCA5-72F76C3AD1DE71CD&ref=p_itune"

Result:
Dialog displayed:
"Error in podcast

There was a problem adding this podcast: Unable to check file type: HTTP Client Error: Forbidden.  Please verify the URL: http://www.pheedo.com/e/b7f9489601ab23c2b3e3516d44e5ac9b/podcast.mp3?e_id=EF83BDDD-E77B-CCA5-72F76C3AD1DE71CD&ref=p_itune. Would you like to add the podcast feed anyway"

Expected result:
Podcast loaded as the file can be downloaded using wget, i.e.:
wget http://www.pheedo.com/e/b7f9489601ab23c2b3e3516d44e5ac9b/podcast.mp3?e_id=EF83BDDD-E77B-CCA5-72F76C3AD1DE71CD&ref=p_itune
Note that that this download is redirected with HTTP 301 and 302 responses.

The error is coming from g_file_query_info() - guessing this function does not handle HTTP redirects.

This is being caused by the HTTP servers response to HEAD requests (which are generated from g_file_query_info):

GET /e/b7f9489601ab23c2b3e3516d44e5ac9b/podcast.mp3?e_id=EF83BDDD-E77B-CCA5-72F76C3AD1DE71CD&ref=p_itune HTTP/1.1
Host:

HTTP/1.1 302 Found
Date: Tue, 06 Oct 2009 03:10:54 GMT
Server: Apache
X-Powered-By: PHP/5.2.3-1ubuntu6.5
Pragma: no-cache
Cache-Control: no-cache, must-revalidate
Location: http://www.sciam.com/podcast/podcast.mp3?e_id=EF83BDDD-E77B-CCA5-72F76C3AD1DE71CD&ref=p_itune
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html

HEAD /e/b7f9489601ab23c2b3e3516d44e5ac9b/podcast.mp3?e_id=EF83BDDD-E77B-CCA5-72F76C3AD1DE71CD&ref=p_itune HTTP/1.1
Host:

HTTP/1.1 403 Forbidden
Date: Tue, 06 Oct 2009 03:11:03 GMT
Server: Apache
X-Powered-By: PHP/5.2.3-1ubuntu6.5
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

Maybe we could look at better ways of handling failed HEAD requests, but the podcast download process isn't going to work very well in that case.

I'm looking at how to avoid doing the HEAD requests as they're not required - you should be able to do a GET request until the headers and then decide if to continue or not (which would be more efficient anyway).  I'm guessing logically this should be achievable with g_file_input_stream_query_info () but it doesn't appear to work for HTTP streams.

Bug 598505 contains a patch to gvfs to allow the headers to be requested using g_file_input_stream_query_info()

Created attachment 145480 [details] [review]
Support using g_file_input_stream_query_info() to get file information for podcasts

Instead of doing a g_file_query_info_async() first it does a g_file_read_async() and if g_file_input_stream_query_info() works uses that and does the download.  If not falls back to using g_file_query_info_async() as before.

Patch to gvfs to support g_file_input_stream_query_info() for HTTP streams is in bug 598505

Created attachment 145481 [details] [review]
Support using g_file_input_stream_query_info() to get file information for podcasts

Forgot to remove the existing line opening the file; it was opening it twice

Is this enough to fix adding the podcast/parsing it, or does totem-pl-parser need a similar fix?

No change is required in totem-pl-parser

Review of attachment 145481 [details] [review]:

needs a better commit message.  should be formatted like this:
  component: brief summary (bug #xxxxxx)

  longer description etc.

::: podcast/rb-podcast-manager.c
@@ +625,2 @@
 static void
+download_error (RBPodcastManagerInfo *data, GError *error, gboolean in_thread)

you don't need the in_thread parameter, just use rb_is_main_thread()

@@ +740,3 @@
+	/* If no stream information then probably using an old version of gvfs, fall back
+	 * to getting the stream information from the GFile.
+	 * This branch can be removed when this version of gvfs is released, see:

no, it can be removed when the minimum requiremend version includes this functionality. not at all the same thing for rhythmbox.

I updated this and pushed it as commit dfc275f