|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #41631 default_socket_timeout does not work with SSL
Submitted: 2007-06-08 01:15 UTC Modified: 2015-03-04 15:59 UTC
Avg. Score:4.8 ± 0.6
Reproduced:143 of 145 (98.6%)
Same Version:106 (74.1%)
Same OS:95 (66.4%)
From: david at acz dot org Assigned: rdlowrey
Status: Closed Package: OpenSSL related
PHP Version: 5.2, 5.3, 5.4, 5.5, 5.6 OS: *
Private report: No CVE-ID:
 [2007-06-08 01:15 UTC] david at acz dot org
The default socket timeout does not work with SSL streams.  An strace shows PHP calls read(2) and blocks forever.

Reproduce code:
Create sleepforever.php:

<? for(;;) sleep(1); ?>

Try it with HTTP:

$ php -n -r 'ini_set("default_socket_timeout", 1); fopen("", "r");'

Now try it with HTTPS:

$ time php -n -r 'ini_set("default_socket_timeout", 1); fopen("", "r");'

Expected result:
Warning: fopen( failed to open stream: HTTP request failed!  in Command line code on line 1

real    0m2.052s
user    0m0.020s
sys     0m0.010s

Actual result:
The process blocks forever.  An strace shows this:

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 1000) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR)             = 0
write(3, "\200j\1\3\1\0Q\0\0\0\20\0\0\26\0\0\23\0\0\n\7\0\300\0\0"..., 108) = 108
read(3, "\26\3\1\0J\2\0", 7)            = 7
*** ELIDED ***
write(3, "\27\3\1\0\30N~h\231u\31S]94^\253\235\26t\324\214\t/\261"..., 29) = 29
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0
read(3, *** THIS BLOCKS FOREVER ***


ssl_read_timeout-5.4.32.patch (last revision 2014-09-29 18:44 UTC) by askalski at synacor dot com)
bug41631.patch (last revision 2014-09-19 15:13 UTC) by

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-06-08 15:58 UTC] david at acz dot org
I have a (partial?) fix:

Index: main/streams/xp_socket.c
RCS file: /repository/php-src/main/streams/xp_socket.c,v
retrieving revision
diff -u -p -d -r1. xp_socket.c
--- main/streams/xp_socket.c    1 Jan 2007 09:36:12 -0000
+++ main/streams/xp_socket.c    8 Jun 2007 15:55:57 -0000
@@ -103,7 +103,7 @@ retry:
        return didwrite;

-static void php_sock_stream_wait_for_data(php_stream *stream, php_netstream_data_t *sock TSRMLS_DC)
+void php_sock_stream_wait_for_data(php_stream *stream, php_netstream_data_t *sock TSRMLS_DC)
        int retval;
        struct timeval *ptimeout;
Index: ext/openssl/xp_ssl.c
RCS file: /repository/php-src/ext/openssl/xp_ssl.c,v
retrieving revision
diff -u -p -d -r1. xp_ssl.c
--- ext/openssl/xp_ssl.c        27 May 2007 17:05:51 -0000
+++ ext/openssl/xp_ssl.c        8 Jun 2007 15:55:57 -0000
@@ -35,6 +35,8 @@
 #include <sys/select.h>

+void php_sock_stream_wait_for_data(php_stream *stream, php_netstream_data_t *sock TSRMLS_DC);
 int php_openssl_apply_verification_policy(SSL *ssl, X509 *peer, php_stream *stream TSRMLS_DC);
 SSL *php_SSL_new_from_context(SSL_CTX *ctx, php_stream *stream TSRMLS_DC);
 int php_openssl_get_x509_list_id(void);
@@ -219,6 +221,12 @@ static size_t php_openssl_sockop_read(ph
        php_openssl_netstream_data_t *sslsock = (php_openssl_netstream_data_t*)stream->abstract;
        int nr_bytes = 0;

+       if (sslsock->s.is_blocked) {
+               php_sock_stream_wait_for_data(stream, &(sslsock->s) TSRMLS_CC);
+               if (sslsock->s.timeout_event)
+                       return 0;
+       }
        if (sslsock->ssl_active) {
                int retry = 1;
 [2008-02-25 21:03 UTC] konstantin dot ryabitsev at mcgill dot ca
This is still happening on 5.2.5, and is really annoying when a soap server you are connecting to accepts the connection and then hangs. Effectively, this quickly results in a denial of service for the entire  site, as the end-result is hung HTTP processes.

Please consider this for a high-priority fix.
 [2008-10-02 08:07 UTC] cunami at gmail dot com
Bug also reproducible on PHP 5.2.4 (2ubuntu5.3).
 [2008-10-03 13:37 UTC] jose dot rodriguez at exec dot cl
reproduced on PHP 5.2.6 @ Windows XP
 [2008-11-02 12:46 UTC]
Please try using this CVS snapshot:
For Windows:

 [2008-11-10 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2008-12-02 23:09 UTC] nvora at yahoo-inc dot com
we are running into the same issue. where can i take a look at the patch? is the fix already checked in to cvs?
 [2009-06-24 15:55 UTC] karl dot debisschop at pearson dot com
Downloaded PHP-2.x-win latest (5.2.11-dev) and confirmed that the issue is still present.
 [2009-06-24 15:58 UTC]
stupid auto no feedback, re assigned.
 [2009-07-02 15:34 UTC] karl dot debisschop at pearson dot com
Just to keep information flowing, I have also tested with windows 5.3.0 and the issue is still present.
 [2009-07-22 03:24 UTC] vergara_rh at yahoo dot com
I would greatly appreciate if this bug will be fix.
 [2009-09-18 10:10 UTC] marcin at php4u dot co dot uk
Still can reproduce on Windows XP SP3, PHP 5.2.6

while connecting to https, script doesn't time out
 [2009-09-24 19:30 UTC]
bug #48524 depends on this fix (

i wish , bug tracking system allowed to be able to close a bug as duplicate of another. then, we could close 48524 as dup of this (41631). this can also trigger the internal score for this bug to be increased (helping in set priority etc). 
 [2009-10-16 20:14 UTC] arkadi dot shishlov at gmail dot com
At least it would be helpful to set TCP keep-alive on socket so OS could timeout it eventually, otherwise there are connections stuck for days.
 [2010-01-18 19:16 UTC] wdierkes at 5dollarwhitebox dot org
This is also reproducible on 5.2.12 as described.  As mentioned 
previously, this has the potentially to have major effects (Denial of 
Servide) etc due to processes hanging and never timing out.  

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.4 (Tikanga)

# php -v
PHP 5.2.12 (cli) (built: Dec 17 2009 12:23:35) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

# uname -a
Linux linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 
x86_64 x86_64 GNU/Linux
 [2010-03-15 10:33 UTC] jason at kapoks dot co dot uk
Had this issue over the weekend with 5.2.10.
Essentially this means our entire service is vulnerable to Denial of Service.

Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux

CentOS release 5.3 (Final)

PHP 5.2.10 (cli) (built: Jun 21 2009 11:10:43)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
 [2010-06-13 15:12 UTC]
-PHP Version: 5.2.11 +PHP Version: 5.2, 5.3
 [2010-06-13 15:12 UTC]
Pierre, doesn't the attached patch fix this issue?
 [2010-11-19 15:43 UTC] chrisw at networkm dot co dot uk
Cannot reproduce this on Windows Server 2003 R2 Enterprise/PHP 5.2.9-2

fopen() returns after $default_socket_timeout seconds if the server does not respond.
 [2011-01-04 00:53 UTC] guyphp at yahoo dot com
This bug has caused us a lot of headaches due to hung connections from partners 
stacking and eventually taking down entire webservers.  During high traffic 
periods, it doesn't take long for these to reach critical mass.  Is there any ETA 
on when this bug will find its way into stable builds?  Like many, our managed 
hosting provider doesn't support patches - we need a stable build with the fix 

We are seeing this problem on 5.2.13, RHEL 5.5.
 [2011-03-28 23:51 UTC] arkadi dot shishlov at gmail dot com
A simple solution is to use HAProxy to proxy SSL partner services. Works for me.
        mode    tcp
        contimeout      5000
        clitimeout      30000
        srvtimeout      30000
 [2011-05-12 17:38 UTC] mgallelli at gmail dot com
i've tested on 5.2.17 and 5.3.2 with the same result.
As described i've used this script:

time php -n -r 'ini_set("default_socket_timeout", 1); 
fopen("", "r");'
but it doesn't wait 1 sec but 15 as into sleep.php page.
 [2013-03-27 11:48 UTC] oxygenus at gmail dot com
This is taking down my servers as well, everytime some other server is down for 
maintainance or some network issue occurs.
 [2013-12-13 09:39 UTC] lobbin at gmail dot com
Honestly, this bug has been open with a potential patch since _2007_. It also contains a perfectly well test case to reproduce the error.
 [2014-03-19 18:02 UTC] alex at modula-shop-systems dot de
Currently *still* experiencing this on this build of php: 

PHP 5.4.26-1~dotdeb.0

What is quite ridiculous for a bug that has been reported nearly 7 years ago ! 

Is it really that difficult to fix this bug? 

It affects also the SoapClient and makes it quite useless / forces ugly fallbacks to CURL when there is a need to catch timeouts over https.

This is really not an uncommon requirement for php in enterprise applications and should simply work.
 [2014-08-07 16:56 UTC]
-Status: Assigned +Status: Closed -PHP Version: 5.2, 5.3 +PHP Version: 5.2, 5.3, 5.4, 5.5, 5.6 -Assigned To: pajoye +Assigned To: rdlowrey
 [2014-08-07 16:56 UTC]
7 years is long enough :)

The problem here was that the SSL_read() function in the relevant code section would block indefinitely waiting for data on a blocking socket connection. The solution was to poll the underlying socket for readable data (adhering to any defined timeouts) before moving on to SSL_read(). If no data arrives in the prescribed time window we now report an error and pull out of the operation.

This issue should be fixed by commit 6569db8 in the 5.4 branch and merged up through to master:

The next series of releases will reflect this fix:

- 5.4.33
- 5.5.17
- 5.6.0-rc4
 [2014-08-07 18:28 UTC] arkadi dot shishlov at gmail dot com
Does the fix work for a situation when some data is available on socket, but SSL_read() wants to read more to process whole record (block encryption)? That may happen on IP packet boundary, depending on the sender. SSL_read() manual is not particularly clear on blocking behavior, but they have the following:

...If no more bytes are in the buffer, SSL_read() will trigger the processing of the next record. Only when the record has been received and processed completely, SSL_read() will return reporting success.

Thank you for the fix in any case!
 [2014-08-07 18:49 UTC]
@arkadi Yes, it's unfortunate but the openssl docs are often unclear on details. As far as I can tell from the relevant openssl source code in the current master branch this should be a non-issue. In the case you mention it appears that SSL_read will simply return the WANT_READ state, not block indefinitely. The initial problem was due to PHP blindly assuming there was data to be read on the socket before launching into a blocking read operation that wouldn't return until *something* was available to consume.

It should be noted that this scenario is a non-issue in non-blocking applications where an fread() on the encrypted stream would only be attempted when data is known to be available. The https:// stream wrapper, though, is fully blocking.

 [2014-08-27 15:03 UTC]
-Status: Closed +Status: Re-Opened
 [2014-08-27 15:03 UTC]
It seems there is a minor issue with the original fix as outlined in this thread:

I'll update this issue once resolved.
 [2014-09-09 16:41 UTC]
-Status: Re-Opened +Status: Closed
 [2014-09-09 16:41 UTC]
This issue should now be resolved via 3728449 which will make its way into the next round of bugfix releases:
 [2014-09-19 11:05 UTC] arhimede at gmail dot com
The fix make the bundled Horde on Plesk 11.5, Centos 6.5 useless

line 116 
feof($this->_stream)  used to return TRUE, now is returning false
 [2014-09-19 13:02 UTC]
-Status: Closed +Status: Re-Opened
 [2014-09-19 15:13 UTC]
The following patch has been added/updated:

Patch Name: bug41631.patch
Revision:   1411139621
 [2014-09-19 15:15 UTC]
I've added a patch that I believe will resolve this issue once and for all. It will apply directly to 5.4 and 5.5. As this bug is exceedingly difficult to test for in isolation I need someone to build php with this patch applied and verify that it resolves the Horde problem.

I will wait for feedback before merging this upstream. Thanks.
 [2014-09-21 22:44 UTC] arhimede at gmail dot com
Plesk just released a patch related to PHP , which fixed the issue with Horde.

I don't know yet if they used the patch from this ticket , so i think you can close it, until further notification.
 [2014-09-22 14:39 UTC] spam2 at rhsoft dot net is alro *re-introduced* with the latest releases from last week - these is something terrible broken with TLS
 [2014-09-22 21:46 UTC] software-php at interfasys dot ch
Patch does not work on released 5.4 and 5.5
 [2014-09-22 22:45 UTC] software-php at interfasys dot ch
All in one patch for #41631 and #67965 for PHP 5.4 and 5.5
 [2014-09-22 23:11 UTC] slusarz at horde dot org
@rdlowery: I'm the author of the Horde code mentioned in this ticket.  Wondering if there is something specific that we are doing that is triggering this issue (we alter the buffer sizes and timeouts after the initial call to stream_socket_client(), for example).

Or is this a more generic issue that simply wasn't caught before the initial patch?

If I get a chance/time, I will try compiling the latest PHP 5.5 from source and verify the latest fix works correctly, at least with the Horde code.
 [2014-09-22 23:20 UTC] software-horde at interfasys dot ch
@slusarz, the patch fixed the issue we had with Horde on PHP 5.4.33 :)
 [2014-09-23 05:06 UTC]
Just to clarify, the working patch posted by software-php at interfasys dot ch is a combination of the patch I posted above with the two commits that were already made to the 5.4 and 5.5 branches but mistakenly left out of the releases due to a miscommunication. You can see those commits here:

These have already been added to the relevant branches.

I would appreciate it if someone could please verify that applying the previously posted patch ( to the current PHP-5.5 and PHP-5.4 branches of the source code resolves the problem so we can eliminate several bugs at once instead of reverting everything and starting back from square one.
 [2014-09-23 05:28 UTC]
@slusarz Thanks for your offer to help. It's nothing specific you guys are doing at Horde -- it's a problem with the encrypted stream code in ext/openssl. These issues were mostly fixed before the releases but due to a miscommunication the relevant commits failed to make it into the 5.4.33 and 5.5.17.

I'm quite sorry these issues made it into release as it has also caused plenty of headaches for me! Some people are quite rude about these sorts of things and don't seem to realize that pretty much everyone who works on php-src does so as an unpaid volunteer (myself included). I definitely appreciate your offer to help. I'll be in touch to let you know as soon as this is fully resolved and/or to ask you guys to do a quick build from source to verify for sure that your problems are addressed.
 [2014-09-24 06:11 UTC] slusarz at horde dot org
@rdlowery: Thanks for the update.  Given @software-horde report that things are working with Horde with the most up-to-date patches, that is sufficient confirmation to me that this has been fixed.

Will let people know from a Horde support perspective that they need to either downgrade for now or wait for the next point release.
 [2014-09-26 08:08 UTC]
Since 5.4 is now in security-fixes mode, and the patch for this issue that got into 5.4.33 was not good, I have reverted the 5.4 branch to its 5.4.32 status for xp_ssl.c. Please verify ASAP that this does not cause additional regressions for 5.4. In 5.5, it still stays as it was before and additional fixes can be applied there if needed.
 [2014-09-26 14:14 UTC] admin at brandensittich dot de
This Problem also affects Roundcube Webmail 1.0.2

PHP 5.5.17-1~dotdeb.1 (cli) (built: Sep 19 2014 01:56:56)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

[26-Sep-2014 16:02:55 Europe/Berlin] PHP Warning:  fgets(): SSL read operation timed out in [...]/program/lib/Roundcube/rcube_imap_generic.php on line 200

     * Reads line from the connection stream
     * @param int  $size  Buffer size
     * @return string Line of text response
    function readLine($size=1024)
        $line = '';

        if (!$size) {
            $size = 1024;

        do {
            if ($this->eof()) {
                return $line ? $line : NULL;

            // Line 200: SSL read operation timed out
            $buffer = fgets($this->fp, $size);

            if ($buffer === false) {
            if ($this->_debug) {
                $this->debug('S: '. rtrim($buffer));
            $line .= $buffer;
        } while (substr($buffer, -1) != "\n");

        return $line;
 [2014-09-26 15:37 UTC] software-php at interfasys dot ch
Even after the patches were applied, Horde could not connect to the sieve server (4190) using TLS, so something is still very wrong.
 [2014-09-26 18:43 UTC] askalski at synacor dot com
I attached a locally-maintained patch for this bug that we've been running in production for the past 3 years.  I'm curious to know if this version of the fix works with Horde?
 [2014-09-28 16:21 UTC] askalski at synacor dot com
Both versions of the patch (bug41631.patch and ssl_read_timeout-5.4.32.patch) need more rigorous testing before they can be released.  I'm willing to help devise a set of tests we can use to validate the implementation.

To illustrate the point without getting to deep into things (it's still the weekend!), here's a test which fails on bug41631.patch, and gives an endless stream of warnings:

/* nonblocking-write.php */
$ssl = fsockopen("ssl://localhost", 6767);
stream_set_blocking($ssl, 0);
while (fwrite($ssl, str_repeat("x", 65536)) !== false);

# Window 1
$ sudo tc qdisc add dev lo root netem delay 100ms
$ openssl s_server -cert server.pem -key server.key -accept 6767 >/dev/null
$ sudo tc qdisc del dev lo root netem delay 100ms

# Window 2
$ php nonblocking-write.php
Warning: fwrite(): SSL operation failed with code 1. OpenSSL Error messages:
error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry in /home/askalski/work/php-bug41631/nonblocking-write.php on line 4

The artificial network delay via the NetEm driver is not required to reproduce the error, but rather makes it more reliable to reproduce.  Don't forget to remove the delay after you're done testing.  You can verify it's removed by checking the ping times of "ping localhost".

If you need to generate a self-signed key for testing with "openssl s_server", here's a quick and dirty way:
$ openssl genrsa -out server.key
$ yes "" | openssl req -new -key server.key -out certreq.csr ; echo
$ openssl x509 -req -days 3650 -in certreq.csr -signkey server.key -out server.pem
 [2014-09-29 15:34 UTC] software-php at interfasys dot ch
I've just tested @askalski's patch and it did not work at all for IMAP per example.
Horde would get completely confused by the replies it got.
 [2014-09-29 18:49 UTC] askalski at synacor dot com
I uploaded a new version of ssl_read_timeout-5.4.32.patch which should fix the issue with Horde's IMAP connection.  The php_openssl_SSL_peek_ok function was calling SSL_read instead of SSL_peek, so the driver occasionally lost 1 byte at the start of a read.  (My guess is this would likely occur only on very low latency connections, which explains why I hadn't yet encountered the bug.)
 [2014-10-02 16:25 UTC]
Hi there folks, just returned from vacation. Can Horde folks verify whether or not @askalski's latest patch resolves their issues?

We're reverting the relevant changes for the upcoming releases so the problem will disappear but I'd like to resolve this so we can fix things and see these changes in subsequent releases.
 [2014-10-02 17:05 UTC] askalski at synacor dot com
We should also solicit feedback about whether this addresses the mysqlnd hang on connect (bug #68046).  I tested it myself and it seems to work, but I would like to hear confirmation from the reporter of that issue.

Also, there are two changes in 5.5.17 that my patch does not include:

1) Bug #67850, which adds two "#ifdef OPENSSL_NO_SSL3" checks to the code.

I'm very curious to know which use case this addresses.  I had no trouble building PHP (without this patch) against OpenSSL 1.0.1i built with the "no-ssl3" option.  I don't mind including this patch regardless, but I would like to satisfy my own curiosity about it (and add some comments to the code for posterity.)

2) Bug #65137, which is intended to help code that uses select/poll on SSL streams.

Although I have not yet come up with a test case to prove it, I suspect that change is not 100% correct.  The big problem with using select() directly on an SSL socket is: even if your application is "writing", a renegotiation behind the scenes may mean OpenSSL needs to block on a "read" (and vice versa.)

So while it certainly helps to drain OpenSSL's internal buffers, the code could still get into a state where it's polling in the wrong direction.  This could cause unwanted blocking, or busy-waiting in the case of a nonblocking socket.

I still need to do more testing with this latter change.  We'll also want feedback from the contributer of that fix (daverandom).
 [2014-10-02 19:37 UTC] software-php at interfasys dot ch
I'm happy to report that @askalski's updated patch is working well for us so far, using Horde. Connections on both IMAP and Sieve work well.

Regarding bug #67850. I provided the patch because PHP would not compile if OpenSSL was not built with SSLv3 support. That's on FreeBSd, compiling OpenSSL from source.
I'm not sure why it works for you in your setup. Maybe PHP picked another OpenSSL in your OS?
 [2014-10-02 21:39 UTC] askalski at synacor dot com
OK, we'll make sure the NO_SSL3 patch doesn't get clobbered.

I didn't get as far in my #65137 testing today as I would have liked.  I just realized that I was tripping over a bug in "openssl s_server", which basically invalidates all of the troubleshooting I did today.
 [2014-10-04 02:24 UTC] askalski at synacor dot com
To give an update, I've started writing tests and have pushed two so far up to my github:

I haven't applied the code changes yet, so one of the tests currently fails.  The other passes because it tests for two bugs which are already fixed on master.
 [2014-10-17 06:40 UTC] fredrik dot eriksson at loopia dot se
I have a problem with SOAP over SSL after the fix in 5.4.33 on FreeBSD. 5.4.32 works fine, but this test case does not work in 5.4.33:

$client = new SoapClient('test.wsdl', array('cache_wsdl' => WSDL_CACHE_NONE, 'trace' => true, 'exceptions' => false, 'connection_timeout' => 15));
$data = $client->get_long_soap_response_over_https($param);

echo "__getLastRequest:\n";
echo $client->__getLastRequest();
echo "\n\n__getLastRequestHeaders:\n";
echo $client->__getLastRequestHeaders();
echo "\n\n__getLastResponse:\n";
echo $client->__getLastResponse();

After the timeout the output for last request and last request headers looks fine, but the response is truncated after a certain size. I didn't save the failed output, but the expected response size was 76800 bytes (+ header), but was truncated I think around 72000 bytes. The same test done over http or with 5.4.32 works fine, so I can only assume that the "fix" for this bug is causing this.
 [2014-10-17 18:22 UTC] askalski at synacor dot com
Does the attached patch (ssl_read_timeout-5.4.32.patch) help with the SoapClient issue?
 [2014-10-20 09:29 UTC] fredrik dot eriksson at loopia dot se
I'm not sure if I understand you correctly, but:

* applying the patch against 5.4.32 works fine, and the problem is not reproducable on the patched php.
* the patch does not apply cleanly against 5.4.33, I didn't bother to try to make it apply since I don't think that would help much.

* when building 5.4.32 with xp_ssl.c from 5.4.33 I see the same problem on 5.4.32
 [2014-10-20 10:44 UTC] software-php at interfasys dot ch
@fredrik, the patch applies cleanly on 32 and 34 (xp_ssl.c is the same). Forget 33, it's broken.

It's great news if it works for you. That means we're one step closer to having a 100% working solution.

A good thing the SSLv3 will be backported as well given the recent news about poodle :)
 [2014-10-24 11:48 UTC] rick at webambition dot nl
We have the same SoapClient SSL issue as fredrik but the PHP version we're on is 5.5.18 (dotdeb on wheezy). The response body is truncated / cut-off around 7000~7999 bytes. 

On PHP 5.5.17 we had connection timeouts but those were fixed by 5.5.18.
 [2014-10-24 12:12 UTC] software-php at interfasys dot ch
@rick, try the patch. It applies cleanly on 5.5.18
 [2014-10-24 14:34 UTC] rick at webambition dot nl
My mistake: PHP 5.5.18 also solved the truncated / incomplete SoapClient responses problem for us. Sorry for the confusion.
 [2015-03-04 15:59 UTC]
-Status: Re-Opened +Status: Closed
PHP Copyright © 2001-2015 The PHP Group
All rights reserved.
Last updated: Fri Mar 06 00:01:03 2015 UTC