Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.FeedsHTTPFetcher only checks for HTTP Status 200 and throws away everything else, which is bad.
I guess it is very common for publishers to advertise clean URLs for their feeds (publisher.com/feed/topic.xml) and then redirecto to various sources, like mediafed or others.
As far as I can see the Fetcher tries to use CURL ( with followlocation option activated ) or
otherwise (in http_request.inc) uses drupal_http_request. The latter can be given a retry parameter to follow
redirects - see http://api.drupal.org/api/function/drupal_http_request/6
Comments
Comment #2
uliOops, sorry I didn't notice that drupal_http_request already has a default of 3 retries
to follow redirects. Both underlying tools (curl and plain drupal_http_request) support
redirects, but nevertheless I get "Download of .... failed with code 302" errors when
adding Feeds in my ManagingNews test environment (same error with curl enabled
or disabled). So this is probably more a bug than a feature request .
Comment #3
alex_b commentedThe fetcher only accepts status 200 from the eventual source. If there are redirects involved, http_request should resolve these redirects and eventually return with the document from the final source and an HTTP status code 200.
Did you find out more about what is failing? Any chance you could provide one of the feeds that are failing here?
Comment #4
uliFirst of all, sorry for not following up for so long. I had to cancel my ManagingNews evaluation, and now
that I turned back to it I was not able to force "...failed with code 302" errors any more, no matter which
feed I tried (strange enough, since I haven't touched anything in the meantime).
So I'm closing this issue, hoping that the problem does not turn up again after I move to the current MN version.
Comment #5
beanworks commentedI am getting the same thing ( Download of ... failed with code 302). Using the beta4 release. I added return FALSE to http_request_use_curl() as discussed in http://drupal.org/node/752862, since there seemed to be some firewall and authentication issues. But this feed is definitely redirecting, and either returns a 0 new feeds report (although there ARE new items available) when run behind a firewall, or a code 302 error when run from an external test site.
Comment #6
beanworks commentedComment #7
alex_b commented#5 - could you provide the feed in question?
Comment #8
David Goode commented