Edit report at http://bugs.php.net/bug.php?id=52323&edit=1
ID: 52323
Updated by: cataphr...@php.net
Reported by: onno at flox dot org
Summary: php_network_connect_socket doesn't return all errors
correctly
Status: Feedback
Type: Bug
Package: Sockets related
PHP Version: trunk-SVN-2010-07-12 (SVN)
Assigned To: pajoye
Block user comment: N
New Comment:
+1 for the first half of the patch.
It doesn't make sense that the return value varies according to whether
the caller is interested in the error string or not...
Previous Comments:
------------------------------------------------------------------------
[2010-09-07 12:46:14] cataphr...@php.net
I think it makes moresense leave php_poll2 untouched.
See http://linux.die.net/man/2/poll, which is being emulated and
http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx which is
being used for the implementation.
The patch in this bug report fills the exceptfds if POLLERR is given,
instead of POLLPRI. However, POLLERR is supposed to be output only as
per poll(2)'s specification.
This way,
* PHP_POLLREADABLE can be given to check if there's data to be read --
although, like the comment in php_poll2 says, it can also mean POLLHUP
and POLLERR. Since we "can't know this without probing", we default to
retuning POLLIN.
* POLLOUT can be given to check if data can be sent/will not block. In
windows, it can also mean a nonblocking connection was successful. We
can't distinguish between the two, so we return POLLOUT.
* POLLPRI can be given to check if processing a connect call
(nonblocking), connection attempt failed or OOB data is available for
reading (only if SO_OOBINLINE is disabled). Again, we can't distinguish
between the two, so we return POLLPRI.
It has to be caller that disambiguates the return value. In Windows, in
case of a nonblocking connect call, we should pass POLLOUT|POLLPRI. When
read the return, we know that POLLOUT means the connection was
successful and POLLPRI means the connection failed (see patch for bug
#50953).
------------------------------------------------------------------------
[2010-09-07 11:59:45] paj...@php.net
hi,
This is related to #50953, can you take a look at the patch and see if
that matches what you have done here? Or if we need to apply your patch
instead, or part of it.
------------------------------------------------------------------------
[2010-07-12 23:07:25] onno at flox dot org
Description:
------------
php_network_connect_socket doesn't return all connection errors (like
ECONNREFUSED) correctly in all cases.
When error_string is NULL, "ret" isn't set to -1, even when "error" is
set. This can cause problems on all platforms. The ftp extension for
example will only detect a socket error once it tries to read the
socket, instead of directly after the call to
php_network_connect_socket.
On Windows, an additional problem exists because of the poll() emulation
in php_poll2: php_network_connect_socket polls for
PHP_POLLREADABLE|POLLOUT, which by php_poll2 is mapped to the readfds
and writefds parameters of select(). In winsock however, connect()
errors are returned in exceptfds, not in writefds like they are in
POSIX. This means the select() call will only return once its timeout
has passed and that php_network_connect_socket will incorrectly return
PHP_TIMEOUT_ERROR_VALUE. This behaviour causes undesired delays in many
functions that (try to) create network connections.
An example of this is the long delay that is observed when connecting to
a MySQL-server using mysqlnd and a hostname that has both an IPv6 and an
IPv4 address: connecting using the IPv6 address will quickly fail, but
because of this bug it will take mysql.connect_timeout seconds before
the IPv4 address is tried.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=52323&edit=1
