using wp_remote_get to retrieve own url on local host

4 comments

1. Ad Timeout

   You should be able to get around the timeout using a filter

   add_filter( 'http_request_timeout', 'wpse35826_timeout_extd' );
   function wpse35826_timeout_extd( $time )
   {
       // Default timeout is 5
       return 10;
   }
   

   Choose the right protocol/scheme

   About your protocol/scheme problem: If it’s your local install, you can use the conditional.

   function wpse35826_remote_get( $args )
   {
       $protocol = is_SSL() ? 'https://' : 'http://';
       $response = wp_remote_get( "{$protocol}test:8888/?p=1" );
       if ( is_wp_error( $response ) )
           return "{$response->get_error_code()}: {$response->get_error_message()}";
   
       return print htmlspecialchars( var_export( $response, true ) );
   }
   
   // Trigger the request
   wpse35826_remote_get();
   

   If you’re doing requests to your own local server, then there might be a problem with the SSL verification. WP uses a filter to trigger it’s setting:

   add_filter( 'https_local_ssl_verify', '__return_false' );
   

   This filter does not(!) trigger for local servers doing requests to a server on the web. For external servers use the following filter:

   add_filter( 'https_ssl_verify', '__return_false' );
   

   Issues with local requests

   Then there also can be issues with blocked local request:

   add_filter( 'block_local_requests', '__return_false' );
   

   Other things that can be influencing your ability to do local requests are constants set wrong in your wp-config.php file:

   WP_HTTP_BLOCK_EXTERNAL
   // If WP_HTTP_BLOCK_EXTERNAL is defined you can add hosts which shouldn't be blocked.
   WP_ACCESSIBLE_HOSTS
   

   In case you’re using Proxies:

   // Allows you to define some adresses which shouldn't be passed through a proxy.
   // Core sets both www and non-www as bypass.
   // get_option('siteurl') and localhost are bypassed by default.
   WP_PROXY_BYPASS_HOSTS
   

   No cURL?

   If there’s cURL not available and you’re not streaming data to a file, WP will fallback to using Fsocketopen() instead. From a core comment, which sums it up nicely:

   Fsocketopen has issues with ‘localhost’ with IPv6 with certain versions of PHP, It attempts to connect to ::1, which fails when the server is not set up for it. For compatibility, always connect to the IPv4 address.

   Point is, that WP only jumps in if we got the host name localhost. The fsocketopen host will then get set to '127.0.0.1'.

   Log in to Reply

2. I had a similar problem and solved it like this:

   function wpse35826_remote_get() {
       $response = wp_remote_get( 'http://test:8888/?p=1' );
       echo 'Response:<pre>';
       print_r($response);
       echo '</pre>';
   }
   add_action('admin_init','wpse35826_remote_get');
   

   Log in to Reply

3. ‘test:8888/?p=1’ isn’t a valid URL.

   Try ‘http://test:8888/?p=1‘ instead.

   Log in to Reply

4. I think you actually have two problems here. Otto’s answer solved your first problem, because leaving the http:// off made it an invalid URL, which is why you got the A valid URL was not provided error.

   The second problem is something different and unrelated, and is giving you the Operation timed out error. I can’t say for sure without seeing your entire code, but I’m guessing that the wp_remote_get() call is inside a callback function which is registered to a hook that is also firing on the page that’s being requested by wp_remote_get(). That situation creates a recursive loop that ultimately times out.

   You need to make sure that wp_remote_get() call isn’t being fired on the page that you’re requesting. You can do that by registering the callback to a different hook, or by using conditional tags to avoid calling wp_remote_get() on the requested page.

   Here’s an example, assuming you’ll always be calling non-admin pages:

   if( !is_admin() )
       return;
   
   $response = wp_remote_get( 'http://test:8888/?p=1' );
   print_r($response);
   

   Log in to Reply