The major problem with this is that its impossible to retrieve the location its being redirected to.

Right now, I'm using wp_remote_head() to check if its redirecting to a different location, Unfortunately thats not possible...

I'll add a patch which adds the location header to the error data objects

But i'm also tempted to suggest, that if its a HEAD request (Or really, any request) and redirects are set to 0, then it shouldnt attempt to redirect at all, and simply return the headers as is (ie. as a 301 with a location header and possibly empty body)

Change History (15)

Half the classes do not support redirections very well, You cant catch the error with some (So cannot tell why the request failed), Not all abide by the max-redirections, and end up returning multiple headers(WP_Http_Fopen at least).

Only really the Curl and FSockopen seem to support redirects well.

I'm going to attach a patch which modifies Curl and FSockopen to return as a normal request, but with a 301/2 error if the max-redirects is 0..

Note, The switching of the Curl error handling order was to allow for the custom 30x error message to have priority over Curl's own internal error. The $parts.. line was also redundant, not being used at all by anything.

Slight bug fix, Turns out that the Streams transport is not returning error-conditional pages, Adding 'ignore_errors' => true fixed that. (Note: a 302 was classified as a error if it was set to not redirect). Result was that it was throwing the error "Could not open handle"

Disabled HEAD requests on one of the transports that cant handle HEAD's. See #11613 for a bug related to that, If a Request is made before it using GET, the result of the test for HEAD will fail as the GET request was cached.

the PHP HTTP Extension is untested, As i dont have access to it. I'm going off the docs on that change, and its mentioned in a comment on that line. Ideally, Once i got to test that transport properly that comment would be removed...