I want to filter any HTTP request URI done through the HTTP API.
Use cases:
- The WordPress update check goes to http://api.wordpress.org/core/version-check/1.6/, but https://api.wordpress.org/core/version-check/1.6/ works too, and I want to use this always.
- The new WordPress file is taken from http://wordpress.org/wordpress-3.4.2.zip, but https://wordpress.org/wordpress-3.4.2.zip works too.
- Sometimes I want to debug requests and redirect those temporary to a custom domain on my local server.
- Some plugins make requests to other servers, and I want to replace these requests when the external server goes down.
The update requests are the most important ones for now, because there is still the unfixed bug 16778 (more information), and HTTPS requests lower the risk of a Man-in-the-middle attack.
I have searched thoroughly, I have studied the core code ⦠but ended up like Nacin two years ago:
I thought for sure you could filter the URL of an HTTP request, but now I can’t find one.
What did I miss? Did I? 🙂
Less than an answer, but just a list of things straight from my experience with it – maybe you’ve overlooked something.
Debugging the request & its results
Without diggin’ too deep into the update process, but the WP HTTP API uses the
WP_HTTP
class. It also offers a nice thing: A debug hook.Where
$response
can also be aWP_Error
object that maybe tells you more.Note: From a brief test, this filter seems to only (for some reason) work if you place it as close to where you’re actually doing the request. So maybe you need to call it from within a callback on one of the below filters.
WP_HTTP
Class argumentsThe Classes arguments itself are filterable, but afaik some get reset by the methods internals back to what WP assumes that is needed.
One of the arguments is
ssl_verify
, which is true by default (but for me causes massive problems when updating from – for example – GitHub). Edit: After debugging a test request, I found another argument that is set to verify if SSL is set totrue
. It’s calledsslverify
(without separating underscore). No idea where this came into the game, if it is actually in use or abandoned and if you have a chance to influence its value. I found it using the'http_api_debug'
filter.Completely custom
You can also “simply” override the whole internals and go with a custom setup. There’s a filter for that.
The first arg needs to be set to true. Than you can interact with the arguments inside
$r
and the result fromparse_url( $url );
.Proxy
Another thing that might work could be running everything through a custom Proxy. This needs some settings in your
wp-config.php
. I’ve never tried this before, but I ran through the constants a while back and summed up some examples that should work and included some comments in case I need it one day. You have to defineWP_PROXY_HOST
andWP_PROXY_PORT
as a min. setting. Else nothing will work and it will simply bypass your proxy.EDIT
The
WP_HTTP
Class normally acts as base class (will be extended for different scenarios). The extendingWP_HTTP_*
classes areFsockopen
,Streams
,Curl
,Proxy
,Cookie
,Encoding
. If you hook a callback to the'http_api_debug'
-action, then the third argument will tell you which class was used for your request.Inside the
WP_HTTP_curl
Class, you’ll find therequest()
method. This method offers two filters to intercept the SSL behavior: One for local requests'https_local_ssl_verify'
and one for remote requests'https_ssl_verify'
. WP will likely definelocal
aslocalhost
and what you get in return fromget_option( 'siteurl' );
.So what I’d do is to try the following right before you do that request (or from a callback that’s hooked to the closest request:
Sidenote: In most cases
WP_HTTP_curl
will be used to handle Proxies.Based on @kaiserâs useful answer I have written some code that seems to work well. That is the reason why I marked it as The Answer.
Let me explain my solution â¦
The logic
When a request it sent through the API is runs through
WP_Http::request()
. Thatâs the method with â¦â¦ in its header. I couldnât agree more.
Now, there are some filters. I decided to misuse
pre_http_request
for my needs:We get three arguments here:
false, $r, $url
.false
is the expected return value forapply_filters()
. If we send anything else back,WordPress stops immediately, and the original request will not be sent.
$r
is an array of arguments for that request. We have to change these too in a minute.$url
is â surprise! â the URL.So in our callback
t5_update_wp_per_https()
we look at the URL, and if it is an URL we want to filter, we say NO to WordPress by not saying ânoâ (false
).Side note: It follows you can prevent all HTTP requests with:
add_filter( 'pre_http_request', '__return_true' );
We fire our own request instead with a better URL and slightly adjusted arguments
(
$r
, renamed to$args
for readability).The code
Please read the inline comments, they are important.
The tests
Without that plugin WordPress used:
http://api.wordpress.org/core/version-check/1.6/
for update checks, andhttp://wordpress.org/wordpress-3.4.2.zip
to download the new files.I tested it with two local installations, a single site and a multi-site setup on Win 7.
To force an update I set
$wp_version
inwp-includes/version.php
to1
and the version ofTwentyEleven to
1.3
.To watch the network traffic I used Wireshark: It is free, it runs on Windows and Linux, and it offers some impressive filter tools.
Watching HTTPS is a little bit difficult: You see just encrypted data ⦠thatâs the idea after all.
To see if my plugin did what it should do I watched the unencrypted traffic first and noted the IP address used to connect to wordpress.org. That was
72.233.56.138
, sometimes72.233.56.139
.Not surprising, there is a load balancer and probably many other tools, so we cannot rely on one IP address.
Then I typed
ip.addr == 72.233.56.138
into the filter mask, activated the plugin, went towp-admin/update-core.php
and watched for the traffic in Wireshark. Green lines are requests in plain text â exactly what we donât want. The red and black lines are a sign of success.The update check went fine: It found the ânewerâ versions. The actual updates for the theme and the core went fine too. Exactly what I needed.
And still ⦠that could be easier if there were a simple filter for the URL.