Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#24182 closed defect (bug) (fixed)

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

Reported by: friedcell Owned by: dd32
Milestone: 3.7 Priority: normal
Severity: normal Version: 2.7
Component: HTTP API Keywords: needs-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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


$url =
$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
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


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.

Attachments (1)

24182.diff (794 bytes) - added by dd32 2 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 @SergeyBiryukov2 years ago

  • Description modified (diff)

comment:2 @friedcell2 years ago

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...

comment:3 @dd322 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Version changed from trunk to 2.7

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.

comment:4 @dd322 years ago

  • Keywords needs-patch added

@dd322 years ago

comment:5 @dd322 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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

comment:6 follow-up: @dd322 years ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone changed from Future Release to 3.7

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:

Host: rest.akismet.com

comment:7 @dd322 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 24845:

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

comment:8 in reply to: ↑ 6 @dd322 years ago

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.

Note: See TracTickets for help on using tickets.