WP_Http_Fsockopen fails when requesting an IP based URL with an explicit Host header

[friedcell]

When requesting a resource with a IP based URL and an explicitly set Host header fsockopen fails.

wp_remote_post():

$url = http://72.233.69.89/1.1/verify-key
$args = Array
(
    [body] => key=xxxxxxxxxxxx&blog=http%3A%2F%2Ffriedcell.si%2Foutbreak
    [headers] => Array
        (
            [Content-Type] => application/x-www-form-urlencoded; charset=UTF-8
            [Host] => rest.akismet.com
            [User-Agent] => WordPress/3.5.1 | Akismet/2.5.7
        )

    [httpversion] => 1.0
    [timeout] => 15
)

WP_Http_Fsockopen $strHeaders just before ​fwrite:

POST /1.1/verify-key HTTP/1.0
Host: 72.233.69.89
User-agent: WordPress/3.5.1 | Akismet/2.5.7
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: rest.akismet.com
Accept-Encoding: deflate;q=1.0, compress;q=0.5
Content-Length: 58

key=xxxxxxxxxxxx&blog=http%3A%2F%2Ffriedcell.si%2Foutbreak

The request fails as the first Host header is used.

When $arrURL['host'] is an IP and there is a Host header in $r['headers'], the Host header should not be added from the URL (​http://core.trac.wordpress.org/browser/trunk/wp-includes/class-http.php#L706) so that the explicitly specified Host header is used.

[friedcell]

I fixed it locally with

if ( ip2long($arrURL['host']) === false && !is_array($r['headers']) || !array_key_exists("Host", $r['headers'])) {

around the if/else that sets the Host header from $arrURLhost? but I'm not sure that handles all the cases...

[dd32]

Confirmed that we've got a hard-coded Host header in the fsockopen handler, and appears that it's been like that since it was first introduced.

It's not as simple as skipping adding the Host header when one is specified, because the Proxy support requires us to alter it.

[dd32]

Attachment 24182.diff​ added

Works for me, Have not tested with a proxy server.

Only fsockopen is affected according to the unit tests added in ​http://core.trac.wordpress.org/changeset/1317/tests

[dd32]

Ah.. That patch by me will completely ignore the actual hostname/IP we're connecting to in the URL.

As for how to handle Proxies, it turns out that the request would look like this:

GET http://72.233.69.89/1.1/verify-key HTTP/1.0
...
Host: rest.akismet.com

[dd32]

In 24845:

WP_HTTP: Fsockopen: Respect a specified Host header in the Fsockopen WP_HTTP transport. Fixes #24182

[dd32]

Replying to dd32:

Ah.. That patch by me will completely ignore the actual hostname/IP we're connecting to in the URL.

Turned out that was wrong, thanks to the $fsockopen_host variable.