I'm accessing a remote SOAP Service that tends to be reacting very slow from time to time (we're talking about more than 10 seconds here).
System is PHP Version 5.3.1, running on Windows Server 2003.
My client is set up like this:
new SoapClient($wsdl, array("trace" => true, "exceptions" => true, "cache_wsdl" => WSDL_CACHE_BOTH, "connection_timeout"=>5000));
Now when I'm shooting a request that takes more than about 10 seconds, the following happens: I get the late but correct response from the service, together with a 200 header (taken from SoapClient::__getLastResponse)
Response Headers:
HTTP/1.1 200 OK Via: 1.1 XXX Connection: Keep-Alive Proxy-Connection: Keep-Alive Content-Length: 430 Date: Mon, 10 Oct 2011 16:03:15 GMT Content-Type: text/xml;charset=UTF-8 Server: Microsoft-IIS/7.5 X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1 X-Powered-By: ASP.NET
But as the SOAP result, I get a SoapFault:
fault:
code: 500
message: An internal error occurred. Please contact our support.
I've tried preventing this with:
ini_set('default_socket_timeout', 5000 );
and setting up the SoapClient with "connection_timeout"=>5000 as seen above. Nothing helps. Any suggestions would be heavily appreciated.
Just had the same problem while accessing a Web Service in SAP and it was not a PHP Bug but a timeout setting in the SAP Web Dispatcher.
I was fighting this for many hours trying to figure out what was wrong with PHP or the SOAP Module.
Finally, I tested in SOAP-UI and the problem was solved quickly. You should do the same with SOAP-UI. Perhaps the Webservice you are calling is depending on another remote connection that has its own timeout settings.
Related
I have come across this header for the first time and not sure what it does or mean. I have searched around and couldn't find what I was looking for.
I am trying to consume a SOAP API using PHP SoapClient class and it's returning an empty response and these response headers. Also, no exception is thrown.
HTTP/1.1 200 OK
X-Backside-Transport: FAIL FAIL,FAIL FAIL
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml
Date: Tue, 21 Jun 2016 20:09:50 GMT
X-Client-IP: xx.xxx.xxx.xxx
Any help is appreciated.
It seems that the web service you're trying to communicate is behind the xml firewall (probably IBM DataPower, it does send X-Backside-Transport header on failere) and blocks the error response (aka. fault message). This is the default behaviour for the xml firewalls. Root cause can be malformed soap message (i.e.: wrong data type) or an server site exception.
In order to solve the problem, you should contact with the web service owner.
I've seen this in the past when communicating with IBM Backends, in my experience it has also been joined with a HTTP 401 Unauthorised.
The reason for the error on my side was because of duplicate headers (e.g. sending the same head twice...)
Hope this helps.
I am working on a PHP script that's processing a lot of data through a SOAP connection. Estimates of the total run time of the script look to be several days if it doesn't encounter any errors. The problem I'm running into is the script will run for a while, anywhere from an hour to a day, and then the SOAP connection will die with the error "error fetching http headers".
I've seen many articles suggesting increasing the default_socket_timeout setting and I've tried this. It hasn't helped. I know it's working cause it makes at least a hundred successful calls before it fails. Is there anything i can do to stop this error?
Update
I printed out the request and response headers hoping to see an error in there. But it appears they are fine:
HTTP/1.1 200 OK
Date: Wed, 25 Sep 2013 21:00:12 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Content-Length: 516
Connection: close
Content-Type: text/xml; charset=UTF-8
as far as example code goes the actual script is crazy long, but the basic premise is this:
ini_set('default_socket_timeout', 120);
$client = new SoapClient($wsdl,array(
'trace' =>true,
'connection_timeout' => 500000,
'cache_wsdl' => WSDL_CACHE_BOTH,
'keep_alive' => true,
));
while(!$finished) {
$finished = $client->someSoapFunction($data);
}
someSoapFunction() will return valid data for 100 of connections and then randomly return me the above error. The time it runs for is less than either of the set timeouts. I'm getting no errors in my php or apache error logs. I'm stumped.
I know it is an old question, but perhaps my solution can be useful to others.
I had the same problem and by changing the 'keep_alive' parameter to false in the creation of the SoapClient object, my problem was solved:
$client = new SoapClient($wsdl,array(
'trace' =>true,
'connection_timeout' => 500000,
'cache_wsdl' => WSDL_CACHE_BOTH,
'keep_alive' => false,
));
I'm trying to get working WSO2 ESB 4.7.0 with PHP 5.4.9 SoapClient.
I've got a problem when I use SoapClient in WSDL mode with ESB echo service, that connection from ESB is not closed after sending WSDL. I'm able to reproduce this problem also with telnet as client.
$ telnet localhost 8280
HTTP 1.0 request:
GET /services/echo?wsdl HTTP/1.0
HTTP 1.0 response:
HTTP/1.0 200 OK
Content-Type: text/xml
Date: Mon, 29 Jul 2013 07:37:20 GMT
Connection: Close
And after response connection stays open (as would stay with "Connection: keep-alive" header).
Is this a bug or problem in configuration? Is anybody experiencing the same problem?
I think I have a similar issue. My LB is querying Version service but after a while the ESB stops responding and a bunch of connection timeouts are visible in the logs. I think the ESB is not releasing its connections. Must be some configuration option to specify to close connection or timeout after a period.
I am using a DocuSign API and have run into some issues.
When sending the data request to their server I am getting the following error:
SoapFault exception: [q0:InvalidSecurity] An error was discovered
processing the <Security> header ---> WSE065: Creation time of the
timestamp is in the future. This typically indicates lack of synchronization
between sender and receiver clocks. Make sure the clocks are synchronized
or use the timeToleranceInSeconds element in the microsoft.web.services3
configuration section to adjust tolerance for lack of clock synchronization.
I have looked all over their community forums and the only response I can find from their forum admin is this:
The message means that the client clock is wrong. The timezone might be set
incorrectly. If the SOAP request is timestamped too far in the future or in the
past, the server will reject it. We generally run into this error with mobile
apps since folks don't always have their devices set to sync to network time.
I checked my server time as well as my computer time to make sure everything is fine. My computer time is set to EST, and the server is set to CST. I have tried updated and synchronized my system clock on my computer as well as trying to adjust my timezone to CST to make sure they both match. I have also changed my computer time to GMT because that is what they say their server time is. I have also tried updating my server's clock since it seems to be the one that is a little bit off. (there seems to be like a 6 minute difference between my clock and the server clock).
I ran this command on the server:
sudo ntpdate ntp.ubuntu.com
Response:
27 Sep 08:51:41 ntpdate[18858]: step time server 91.189.94.4 offset -357.639332 sec
I also tried editing my grub configuration file on the server (/boot/grub/grub.conf). I tried adding different combinations of these params to the end of the kernel line:
clock=pit
acpi=off
noapic
As well as trying to update the hardware clock with this command:
hwclock=systohc
The soap headers are as follows:
This request was sent out at 10:41AM(my computer time [EST]), 9:47AM (my server time [CST]).
Request:
POST /api/3.0/api.asmx HTTP/1.1
Host: www.docusign.net
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.3.16
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.docusign.net/API/3.0/CreateEnvelope"
Content-Length: 116157
Response:
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Length: 1696
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Thu, 27 Sep 2012 14:41:13 GMT
Vary: Accept-Encoding
Strict-Transport-Security: max-age=7776000; includeSubDomains
If anyone has any thoughts as to what might be causing this error, or if anyone has any further advice on how to go about synchronizing my clocks, I would love to hear them.
Thanks in advance for your time and consideration.
I ended up contacting the company I am hosting my virtual server with and as it turns out it wasn't an issue with anything I have control over at all. It turned out that their hypervisor (virtual machine monitor - VMM) was having issues so when my server was synchronizing its time from it, my time was getting offset by about 7 minutes. Since the system clock of my server was being controlled by it, this also disallowed me from being able to set the time manually with this command:
date -s "27 SEP 2012 HH:MM:SS"
since the changes would just be superseded by the VMM.
Morning all
Basically, I am unable to make successful cURL requests to internal and external servers from my Windows 7 development PC because of an issue involving a proxy server. I'm running cURL 7.21.2 thru PHP 5.3.6 on Apache 2.4.
Here's a most basic request that fails:
<?php
$curl = curl_init('http://www.google.com');
$log_file = fopen(sys_get_temp_dir() . 'curl.log', 'w');
curl_setopt_array($curl, array(
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_VERBOSE => TRUE,
CURLOPT_HEADER => TRUE,
CURLOPT_STDERR => $log_file,
));
$response = curl_exec($curl);
#fclose($log_file);
print "<pre>{$response}";
The following (complete) response is received.
HTTP/1.1 400 Bad Request
Date: Thu, 06 Sep 2012 17:12:58 GMT
Content-Length: 171
Content-Type: text/html
Server: IronPort httpd/1.1
Error response
Error code 400.
Message: Bad Request.
Reason: None.
The log file generated by cURL contains the following.
* About to connect() to proxy usushproxy01.unistudios.com port 7070 (#0)
* Trying 216.178.96.20... * connected
* Connected to usushproxy01.unistudios.com (216.178.96.20) port 7070 (#0)
> GET http://www.google.com HTTP/1.1
Host: www.google.com
Accept: */*
Proxy-Connection: Keep-Alive
< HTTP/1.1 400 Bad Request
< Date: Thu, 06 Sep 2012 17:12:58 GMT
< Content-Length: 171
< Content-Type: text/html
< Server: IronPort httpd/1.1
<
* Connection #0 to host usushproxy01.unistudios.com left intact
Explicitly stating the proxy and user credentials, as in the following, makes no difference: the response is always the same.
<?php
$curl = curl_init('http://www.google.com');
$log_file = fopen(sys_get_temp_dir() . 'curl.log', 'w');
curl_setopt_array($curl, array(
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_VERBOSE => TRUE,
CURLOPT_HEADER => TRUE,
CURLOPT_STDERR => $log_file,
CURLOPT_PROXY => 'http://usushproxy01.unistudios.com:7070',
CURLOPT_PROXYUSERPWD => '<username>:<password>',
));
$response = curl_exec($curl);
#fclose($log_file);
print "<pre>{$response}";
I was surprised to see an absolute URL in the request line ('GET ...'), but I think that's fine when dealing with proxy servers - according to the HTTP spec.
I've tried all sorts of combinations of options - including sending a user-agent, following this and that, etc, etc - having been through Stack Overflow questions, and other sites, but all requests end in the same response.
The same problem occurs if I run the script on the command line, so it can't be an Apache issue, right?
If I make a request using cURL from a Linux box on the same network, I don't experience a problem.
It's the "Bad Request" thing that's puzzling me: what on earth is wrong with my request? Do you have any idea why I may be experiencing this problem? A Windows thing? A bug in the version of PHP/cURL I'm using?
Any help very gratefully received. Many thanks.
You might be looking at an issue between cURL (different versions between Windows and Linux) and your IronPort version. In IronPort documentation:
Fixed: Web Proxy uses the Proxy-Connection header instead of the
Connection header, causing problems with some user agents
Previously, the Web Proxy used the Proxy-Connection header instead of the
Connection header when communicating with user agents with explicit
forward requests. Because of this, some user agents, such as Real
Player, did not work as expected. This no longer occurs. Now, the Web
Proxy replies to the client using the Connection header in addition to
the Proxy-Connection header. [Defect ID: 46515]
Try removing the Proxy-Connection (or add a Connection) header and see whether this solves the problem.
Also, you might want to compare the cURL logs between Windows and Linux hosts.