Allow provider result of 302

Can this perhaps be closed out?

Since emfield_request_xml calls drupal_http_request (see http://api.drupal.org/api/function/drupal_http_request/5), and drupal_http_request handles redirects (including 302), testing for 302 here shouldn't be necessary.

And if it is not dealing with 302 perhaps this is a core issue.

I belleve Winston is correct. I'm closing this out. Thanks!

Actually winston is NOT correct! I know it's a shocker ;)

Markus Sandy is in fact correct. It appears that emfield_request_xml is breaking in the way that is uses the results from the core "drupal_http_request" function. Apologies to markus sandy for not picking up on that.

The trick here is that the drupal_http_request function DOES properly handle 302 by recursively attempting again on the redirected location (up to $retry which defaults to 3 times). HOWEVER, after it comes back from that it does not change the code to 200. Here is an example of what the drupal_http_request returns (in print_r) format in a case where the file it is hitting returns a 302, but on the redirect successfully returns the ultimate target file...

Note: The original request URL is "http://www.archive.org/download/Magellan/Magellan_files.xml"

Note that it successfully returned the xml file and indicated that via [redirect_code] => 200, but still indicated [code] => 302 since that was the initial report from the file. This makes total sense on the part of the core drupal_http_request as the calling application may very well want to know that a redirect occurred so that the ultimate target can be stored if needed ([redirect_url] shows where it actually ended up getting the file from after the redirect).

So where does that leave us. Well markus sandy's report of error is certainly correct. Emfield is not using drupal_http_request correctly (unless the intent is to fail even when a standard 302 redirect would work). However I disagree with his proposed solution. The source code for drupal_http_request contains the correct answer for us and it is quite simple! If drupal_http_request fails even after retries/redirects then it returns $result->error = $text;

So we simply need to test for a non-empty $result->error! Yeah.

Anyway here is the one-line patch to fix this problem in emfield.module. I did a quick test which appears to confirm that this is the correct way to go.

markus sandy, again my apologies.

Note that I modified this to the latest version (best practice I believe?) Presumably a similar patch against the 5.x branch would also work.

Shouldn't that be:

;-)

Thank you Rob. Here is it again with that correction.

got it, thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.