Error fetching http headers in SoapClient

PhpSoap Client

Php Problem Overview

I'm trying to invoke a WS over https on a remote host:remote port and I get:

> Error fetching http headers

using the PHP5 SoapClient; I can get the list of functions by doing $client->__getFunctions() but when I call $client->myFunction(...) I always get this error.

I've googled and found that increasing default_socket_timeout in php.ini should fix it, but it did not work.

Can anyone suggest me a solution?

EDIT: here is the code:

$wsdl="myWSDL";

$client = new SoapClient($wsdl,array('connection_timeout'=>5,'trace'=>true,'soap_version'=>SOAP_1_2));

var_dump($client->__getFunctions());

try {
	$response=$client->myFunction("1","2","3");
         } catch (SoapFault $fault) {
    var_dump($fault);
    }
}

always ends in the error.

How do I solve the problem?

Php Solutions

Solution 1 - Php

This error is often seen when the default_socket_timeout value is exceeded for the SOAP response. (See this link.)

Note from the SoapClient constructor: the connection_timeout option is used for defining a timeout value for connecting to the service, not for the timeout for its response.

You can increase it like so:

ini_set('default_socket_timeout', 600); // or whatever new value you want

This should tell you if the timeout is the issue, or whether you have a different problem. Bear in mind that you should not use this as a permanent solution, but rather to see if it gets rid of the error before moving on to investigate why the SOAP service is responding so slowly. If the service is consistently this slow, you may have to consider offline/batch processing.

Solution 2 - Php

Just wanted to share the solution to this problem in my specific situation (I had identical symptoms). In my scenario it turned out to be that the ssl certificate provided by the web service was no longer trusted. It actually turned out to be due to a new firewall that the client had installed which was interfering with the SOAP request, but the end result was that the certificate was not being correctly served/trusted.

It was a bit difficult to track down because the SoapClient call (even with trace=1) doesn't give very helpful feedback.

I was able to prove the untrusted certificate by using:

openssl s_client -connect <web service host>:<port>

I know this won't be the answer to everyone's problem, but hopefully it helps someone. Either way I think it's important to realise that the cause of this error (faultcode: "HTTP" faultstring: "Error Fetching http headers") is usually going to be a network/socket/protocol/communication issue rather than simply "not allowing enough time for the request". I can't imagine expanding the default_socket_timeout value is going to resolve this problem very often, and even if it does, surely it would be better to resolve the issue of WHY it is so slow in the first place.

Solution 3 - Php

I suppose it's too late, but I have the same problem. I try the socket timeout but it doesn't work. My problem was that the client and the server where in the same physical server. With the client code working in the same physical server , I get this error, but, with the same client code moved to my localhost, requesting the server, (client and server was executed in two differents mechines) all works fine.

Maybe that can help someone else!

Solution 4 - Php

I faced same problem and tried all the above solutions. Sadly nothing worked.

  1. Socket Timeout (Didn't work)
  2. User Agent (Didn't work)
  3. SoapClient configuration, cache_wsdl and Keep-Alive etc...

I solved my problem with adding the compression header property. This is actually required when you are expecting a response in gzip compressed format.

//set the Headers of Soap Client. 
$client = new SoapClient($wsdlUrl, array(
	'trace' => true, 
	'keep_alive' => true,
	'connection_timeout' => 5000,
	'cache_wsdl' => WSDL_CACHE_NONE,
	'compression'   => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | SOAP_COMPRESSION_DEFLATE,
));

Hope it helps.

Good luck.

Solution 5 - Php

Setting 'keep_alive' to false worked for me:

new SoapClient($api_url, array('keep_alive' => false));

Solution 6 - Php

The configuration that has worked for me was defining at my php script the following parameters:

ini_set('default_socket_timeout', 5000);
$client = new \SoapClient($url,array(
    'trace' =>true,
    'connection_timeout' => 5000,
    'cache_wsdl' => WSDL_CACHE_NONE,
    'keep_alive' => false,
));

Please, comment.

The most important parameter definition, as per my experience with this issue was

ini_set('default_socket_timeout', 5000);

During my tests I have defined the default_socket_timeout to 5 seconds and the error 'Error Fetching http headers' was raised instantaneously.

I hope it helps you!

Solution 7 - Php

I just wanted to add, for completeness sake, that similar to Manachi I received this message because the client certificate I was using required a passphrase and I accidentally had an extra character at the end of the passphrase. This post is just to offer up another suggestion for what to look into. If the host requires the use of a client certificate (via local_cert parameter) make sure you provide the correct path to the cert and the correct passphrase (if one is needed). If you don't, it is very likely you will see this same error message.

Solution 8 - Php

None of the above techniques worked for me.

When I analyzed the request header from __getLastRequestHeaders, I saw the following:

POST /index.php/api/index/index/?SID=012345 HTTP/1.1 Host: www.XYZ.com

The API URL I had been using was different, like www.ABC.com. I changed the API URL to www.XYZ.com/index.php/api?wsdl, and then it worked.

Both URLs returned the same WSDL from the same server, but only one allowed login.

Solution 9 - Php

I had this problem and I checked, and in my case, was the Firewall. The PHP not show the error correctly. To perform the request, the Firewall answered:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
...
<html
...
<h1>Direct Access IP is not allowed</h1>
...
</html>

The SoapClient expects the SOAP envelope but receives a HTML code. That's why PHP responds with: "Error Fetching Http Headers" because it can not understand what he received in response. To resolve the problem, contact your network administrator to verify if there is any Firewall, NAT or proxy getting in the way and then ask them to make the necessary arrangements.

Solution 10 - Php

Please check for the response HTTP-Header. In my case, the following header was set on the API-Site:

<IfModule mod_headers.c>
    Header set Connection keep-alive
</IfModule>

It seems like the PHP SoapClient can't deal with that option. As a result, the response body was empty, but content-length in the response-header has been set correctly.

Remove that line or change it to "close" solved my issue.

Solution 11 - Php

I had the same issue and tried the following by disabling keep_alive.

$api_proxy = new SoapClient($api_url, array('trace' => true, 'keep_alive' => false));

However, that didn't work for me. What worked worked for me was disabling the SOAP cache. It appears to have been caching the wrong requests and after disabling I actually noticed my requests were executing faster.

On a linux server you can find this in your /etc/php.ini file.

Look for soap.wsdl_cache_enabled=1 and change it to soap.wsdl_cache_enabled=0.

Don't forget to reload apache. service httpd reload

Solution 12 - Php

Another possible cause of this error could be some OpenSSL operations leaving not cleared errors. Put this piece of code before the SOAP request to clear them:

while (openssl_error_string()) {}

Solution 13 - Php

I got this same error and in my case the server I was sending the request to was replying with a 504 Gateway Time-out error. I didn't realize this until I went to the URL in a browser that was being requested by the SOAP request:

eg. https://soap-request-domain-here.com/path/to/file.wsdl

Solution 14 - Php

We encountered Error fetching http headers on every second call of SoapClient::__soapCall(,). However, not every soap endpoint/soap server was affected.

It turned out that switching to http was working reliably for all servers, but connections via https/secure HTTP showed above symptoms. The openssl_error_string() as suggested by Furgas did not return any errors.

It turned out that the misbehaving soap servers sent a HTTP-header with every response which lead to the soap client choking on the second soap call: Connection: Upgrade, close. The well-behaving servers did not send a Upgrade on successive responses.

What worked for us:

  • setting keep_alive to false, as mentioned by Thiago
  • unsetting the Upgrade- and Connection-headers via .htaccess files

Although the well-behaving soap servers did not need any of this, the misbehaving once needed both the keep_alive set to false and the unsetting of the headers.

# .htaccess
Header unset Upgrade
Header unset Connection

The root-cause is still unclear, but there is a bug report at Apache regarding Upgrade headers when using HTTPS.

Solution 15 - Php

In recent releases from Zend SOAP client not having "connection_timeout" and "Keep_alive" parameters at all.

[![enter image description here][1]][1]

You can see the piece of code I have attached as an image. The only way to solve this issue to increase your default socket timeout in php.ini

default_socket_timeout = 1000

I hope it will solve your issue. Give an upvote if it works. [1]: https://i.stack.imgur.com/6LqSy.png

Categories
Recommended Php Solutions

Previous Solution:

Finding the max value in a map

C++DictionaryVectorMaxMode

Next Solution:

How to compile Clang on Windows

C++CWindowsClang

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionCrisView Question on Stackoverflow
Solution 1 - PhpcmbuckleyView Answer on Stackoverflow
Solution 2 - PhpManachiView Answer on Stackoverflow
Solution 3 - PhpJonathan HuetView Answer on Stackoverflow
Solution 4 - PhpSanjay MohnaniView Answer on Stackoverflow
Solution 5 - PhpThiago SathlerView Answer on Stackoverflow
Solution 6 - PhpMarcelo Tonon ChiovattoView Answer on Stackoverflow
Solution 7 - PhpborqView Answer on Stackoverflow
Solution 8 - PhphumbadsView Answer on Stackoverflow
Solution 9 - PhpMauroView Answer on Stackoverflow
Solution 10 - PhpMatthias KleineView Answer on Stackoverflow
Solution 11 - PhpMagentoManView Answer on Stackoverflow
Solution 12 - PhpFurgasView Answer on Stackoverflow
Solution 13 - PhpJohn LangfordView Answer on Stackoverflow
Solution 14 - PhpRichard KieferView Answer on Stackoverflow
Solution 15 - PhpsivaprakashView Answer on Stackoverflow