php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67292 SoapClient posts on connection closed by server
Submitted: 2014-05-16 12:05 UTC Modified: 2014-07-28 13:57 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: ghpille at hotmail dot com Assigned:
Status: Open Package: SOAP related
PHP Version: 5.4Git-2014-05-16 (snap) OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2014-05-16 12:05 UTC] ghpille at hotmail dot com
Description:
------------
A PHP script instantiates two SoapClients, and makes two succesful requests using the first.  Now and then, the server closes the connnection after replying to the second request, by sending a FIN packet, which is ACKnowledged by the client.  The client makes two succesful requests using the second client, and tries to make a third one using the first client.  The server rejects the packets from the third request (a RST is sent for each packet received), and the client complains: "Fatal error: Uncaught SoapFault errors fetching http headers".

The client knows the connection has been closed, since recv returns 0.  In most cases, a new connection will be established, but now and then, the client disregards the closure.

From a TCP point of view, the client may send data before closing its side of the connection, but from an application point of view it makes no sense to post a request and expect an answer.

A tcpdump of the failing post: https://groups.google.com/forum/#!topic/comp.lang.php/52KxyhoUw_s

When I posted this, I had not yet realized the server had closed the connection earlier on.

Problem first noticed on a CentOS 6.5 VMWare client, reproducible on Debian Wheezy physical system, 32+64bit,  PHP 5.4 and 5.5.

PHP Version => 5.4.30-dev
System => Linux ghp-debian-vm 3.2.0-4-486 #1 Debian 3.2.54-2 i686
Build Date => May 16 2014 13:34:15
Configure Command =>  './configure'  '--enable-soap'


Expected result:
----------------
SoapClient should establish a new connection, as it does usually.

13:35:18.192641 poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])
13:35:18.192693 recv(3, "", 1, MSG_PEEK) = 0
13:35:18.192732 close(3)                = 0
... resolve host address ...
13:35:18.197776 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
13:35:18.197830 fcntl64(3, F_GETFL)     = 0x2 (flags O_RDWR)
13:35:18.197871 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
13:35:18.197913 connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("172.16.2.173")}, 16) = -1 EINPROGRESS (Operation now in progress)
13:35:18.198091 poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=3, revents=POLLOUT}])
13:35:18.199010 getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
13:35:18.199061 fcntl64(3, F_SETFL, O_RDWR) = 0
13:35:18.199129 send(3, "POST /roularta-jobcv-dao/service"..., 8192, MSG_DONTWAIT) = 8192
13:35:18.199391 send(3, "e7b887b8f813f353/eee99b2a98dfda4"..., 352, MSG_DONTWAIT) = 352
13:35:18.199446 poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=3, revents=POLLIN}])
13:35:18.223129 recv(3, "HTTP/1.1 200 OK\r\nDate: Fri, 16 M"..., 8192, MSG_DONTWAIT) = 198


Actual result:
--------------
13:35:16.570135 poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])
13:35:16.570184 recv(3, "", 1, MSG_PEEK) = 0
13:35:16.570233 send(3, "POST /roularta-jobcv-dao/service"..., 8192, MSG_DONTWAIT) = 8192
13:35:16.570527 send(3, "e7b887b8f813f353/eee99b2a98dfda4"..., 352, MSG_DONTWAIT) = 352
13:35:16.570577 poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=3, revents=POLLIN}])
13:35:16.570629 recv(3, "", 8192, MSG_DONTWAIT) = 0
13:35:16.570669 close(3)                = 0
13:35:16.571069 write(1, "\nFatal error: Uncaught SoapFault"..., 429) = 429


Patches

main_streams_xp_socket_eof (last revision 2014-05-19 14:19 UTC) by ghpille at hotmail dot com)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-05-19 08:28 UTC] ghpille at hotmail dot com
When php_stream_eof is checked, after the server sent its FIN packet, it returns false when it should be true.

This is caused by stream->eof being false OR php_stream_set_option not returning PHP_STREAM_OPTION_RETURN_ERR when it should

        if (!stream->eof && PHP_STREAM_OPTION_RETURN_ERR ==
                        php_stream_set_option(stream, PHP_STREAM_OPTION_CHECK_LIVENESS,
                        0, NULL)) {
                stream->eof = 1;
        }
        return stream->eof;
 [2014-07-28 13:57 UTC] ghpille at hotmail dot com
Exact error message is:

Fatal error: Uncaught SoapFault Exception [HTTP] error fetching http headers
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC