FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

ID: 18335
Updated by: alec@alec.pl
Reported By: dunix at gmx dot de
Summary: Attachments broken
Status: Feedback
Type: Bug
Package: Net_SMTP
Operating System: Gentoo Linux
Package Version: 1.5.1
PHP Version: 5.3.5
Assigned To: jon
Roadmap Versions:
New Comment:

Because Roundcube webmail users complain about similiar issue I'll try
to help. 1.5.1 is still a problem. I feel it can be related to
http://pear.php.net/bugs/bug.php?id=18262 and
http://bugs.php.net/bug.php?id=39598

I don't know how to reproduce this, but can imagine that socket's
fwrite() (in socket's write() method) returns 0. In this case _send()
doesn't return error and data() will continue the loop over all chunks
of data. Final _send("\r\n.\r\n") can also not return an error.

It looks that we could detect "0" response from write(), then sleep for
some short time and try again. I don't know how it can be related to
socket timeout. Maybe fwrite returns 0 after timeout is reached or sth
or it's an other issue.


Previous Comments:
------------------------------------------------------------------------

[2011-03-30 12:06:52] passembk

I don't know if this is helpful, but I installed xdebug to trace the
problem. Here is the relevant output:

The first trace shows what happened when the e-mail got through without
being cut off:
0,6897 18185088 -> Net_SMTP->_send($data = '...')
/usr/share/php/Net/SMTP.php:1036
0,6897 18310152 -> Net_SMTP->_debug($message =
'...') /usr/share/php/Net/SMTP.php:250
0,6897 18185088 -> Net_Socket->write($data = '...',
$blocksize = ???) /usr/share/php/Net/SMTP.php:252
0,6897 18185184 -> is_resource(resource(108) of
type (stream)) /usr/share/php/Net/Socket.php:379
=> TRUE
0,6897 18185184 -> is_null(NULL)
/usr/share/php/Net/Socket.php:383
=> TRUE
0,6897 18185184 -> fwrite(resource(108) of type
(stream), '...') /usr/share/php/Net/Socket.php:384
=> 124991
=> 124991
The second trace shows what happend when the same e-mail was cut off:
0,6897 18109824 -> Net_SMTP->_send($data = '...')
/usr/share/php/Net/SMTP.php:1036
0,6897 18234888 -> Net_SMTP->_debug($message =
'...') /usr/share/php/Net/SMTP.php:250
0,6897 18109824 -> Net_Socket->write($data = '...',
$blocksize = ???) /usr/share/php/Net/SMTP.php:252
0,6897 18109920 -> is_resource(resource(108) of
type (stream)) /usr/share/php/Net/Socket.php:379
=> TRUE
0,6897 18109920 -> is_null(NULL)
/usr/share/php/Net/Socket.php:383
=> TRUE
0,6897 18109920 -> fwrite(resource(108) of type
(stream), '...') /usr/share/php/Net/Socket.php:384
=> 65536
=> 65536
Additionally, the fwrite function generated the following notice:
fwrite(): send of 8192 bytes failed with errno=11 Resource temporarily
unavailable in /usr/share/php/Net/Socket.php on line 384

------------------------------------------------------------------------

[2011-03-28 16:55:37] jon

-Status: Assigned
+Status: Feedback
The attached patch changed the behavior to only set the socket timeout
if a
connection timeout was specified. That effectively removes all
non-default timeout
behavior, which is not the goal of the feature.

In its default mode, the current 1.5.1 code should default to an
infinite socket timeout
(timeout = 0).

So I'm a little confused what's causing the problematic behavior (an
overly-short
timeout that's tearing down the connection for large transfers).

------------------------------------------------------------------------

[2011-03-27 13:53:55] doconnor

1.5.0 appeared to exhibit this behaviour for us, and 1.5.1 resolved it.
WFM.

------------------------------------------------------------------------

[2011-03-22 23:44:46] passembk

Sorry for the confusion, dunix and passembk are both my accounts.

I could reproduce the problem on two different machines. The patch that
I attached fixed it on both of them.

Let me know if you need more information or if there is anything else
that I could test.

------------------------------------------------------------------------

[2011-03-22 05:52:05] jon

Great; it sounds like this is reproducible for many people. Could you
trying
attempting some of the timeout changes suggested in the comments to see
if they
make a difference?

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://pear.php.net/bugs/bug.php?id=18335

Search Discussions

  • Grosjo at Apr 13, 2011 at 5:38 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Comment by: grosjo
    Reported By: joan at gj-pro dot net
    Summary: Attachments broken
    Status: Feedback
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    New Comment:

    Hi,

    I am very interested in fixing this issue , using RoundCube and other
    softs based on this class.

    Please let me know if I can help in some way.
    Thanks
    Joan


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-13 09:54:20] alec

    Because Roundcube webmail users complain about similiar issue I'll try
    to help. 1.5.1 is still a problem. I feel it can be related to
    http://pear.php.net/bugs/bug.php?id=18262 and
    http://bugs.php.net/bug.php?id=39598

    I don't know how to reproduce this, but can imagine that socket's
    fwrite() (in socket's write() method) returns 0. In this case _send()
    doesn't return error and data() will continue the loop over all chunks
    of data. Final _send("\r\n.\r\n") can also not return an error.

    It looks that we could detect "0" response from write(), then sleep for
    some short time and try again. I don't know how it can be related to
    socket timeout. Maybe fwrite returns 0 after timeout is reached or sth
    or it's an other issue.

    ------------------------------------------------------------------------

    [2011-03-30 12:06:52] passembk

    I don't know if this is helpful, but I installed xdebug to trace the
    problem. Here is the relevant output:

    The first trace shows what happened when the e-mail got through without
    being cut off:
    0,6897 18185088 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18310152 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18185088 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18185184 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18185184 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18185184 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 124991
    => 124991
    The second trace shows what happend when the same e-mail was cut off:
    0,6897 18109824 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18234888 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18109824 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18109920 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18109920 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18109920 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 65536
    => 65536
    Additionally, the fwrite function generated the following notice:
    fwrite(): send of 8192 bytes failed with errno=11 Resource temporarily
    unavailable in /usr/share/php/Net/Socket.php on line 384

    ------------------------------------------------------------------------

    [2011-03-28 16:55:37] jon

    <div id="changeset">
    <span class="removed">-Status: Assigned</span>
    <span class="added">+Status: Feedback</span>
    </div>The attached patch changed the behavior to only set the socket
    timeout if a
    connection timeout was specified. That effectively removes all
    non-default timeout
    behavior, which is not the goal of the feature.

    In its default mode, the current 1.5.1 code should default to an
    infinite socket timeout
    (timeout = 0).

    So I'm a little confused what's causing the problematic behavior (an
    overly-short
    timeout that's tearing down the connection for large transfers).

    ------------------------------------------------------------------------

    [2011-03-27 13:53:55] doconnor

    1.5.0 appeared to exhibit this behaviour for us, and 1.5.1 resolved it.
    WFM.

    ------------------------------------------------------------------------

    [2011-03-22 23:44:46] passembk

    Sorry for the confusion, dunix and passembk are both my accounts.

    I could reproduce the problem on two different machines. The patch that
    I attached fixed it on both of them.

    Let me know if you need more information or if there is anything else
    that I could test.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Pear at Apr 14, 2011 at 9:20 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Comment by: pear@thequod.de
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    Status: Feedback
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    The problem here is quite trivial: a timeout of 0 seconds will (set via
    Net_SMTP::setTimeout => Net_Socket::setTimeout => socket_set_timeout)
    will make the socket time out after 0 seconds, which means "nearly
    instantly" and will only happen with a large amount of data.

    I've attached a patch to change the default timeout to 30 seconds
    instead.

    Even when "0" would have meant "never" here, it would not have been a
    good default.

    The problem however is two-fold, because Net_Socket does not properly
    catch the timeout, and no error is returned in that case. I will submit
    a patch for Net_Socket, too (see bug #18281)
    Given that patch for Net_Socket and a timeout of 0, you would get an
    error instead (for a "larger amount of data").


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-13 18:10:15] grosjo

    Hi,

    I am very interested in fixing this issue , using RoundCube and other
    softs based on this class.

    Please let me know if I can help in some way.
    Thanks
    Joan

    ------------------------------------------------------------------------

    [2011-04-13 09:54:20] alec

    Because Roundcube webmail users complain about similiar issue I'll try
    to help. 1.5.1 is still a problem. I feel it can be related to
    http://pear.php.net/bugs/bug.php?id=18262 and
    http://bugs.php.net/bug.php?id=39598

    I don't know how to reproduce this, but can imagine that socket's
    fwrite() (in socket's write() method) returns 0. In this case _send()
    doesn't return error and data() will continue the loop over all chunks
    of data. Final _send("\r\n.\r\n") can also not return an error.

    It looks that we could detect "0" response from write(), then sleep for
    some short time and try again. I don't know how it can be related to
    socket timeout. Maybe fwrite returns 0 after timeout is reached or sth
    or it's an other issue.

    ------------------------------------------------------------------------

    [2011-03-30 12:06:52] passembk

    I don't know if this is helpful, but I installed xdebug to trace the
    problem. Here is the relevant output:

    The first trace shows what happened when the e-mail got through without
    being cut off:
    0,6897 18185088 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18310152 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18185088 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18185184 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18185184 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18185184 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 124991
    => 124991
    The second trace shows what happend when the same e-mail was cut off:
    0,6897 18109824 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18234888 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18109824 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18109920 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18109920 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18109920 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 65536
    => 65536
    Additionally, the fwrite function generated the following notice:
    fwrite(): send of 8192 bytes failed with errno=11 Resource temporarily
    unavailable in /usr/share/php/Net/Socket.php on line 384

    ------------------------------------------------------------------------

    [2011-03-28 16:55:37] jon

    -Status: Assigned
    +Status: Feedback
    The attached patch changed the behavior to only set the socket timeout
    if a
    connection timeout was specified. That effectively removes all
    non-default timeout
    behavior, which is not the goal of the feature.

    In its default mode, the current 1.5.1 code should default to an
    infinite socket timeout
    (timeout = 0).

    So I'm a little confused what's causing the problematic behavior (an
    overly-short
    timeout that's tearing down the connection for large transfers).

    ------------------------------------------------------------------------

    [2011-03-27 13:53:55] doconnor

    1.5.0 appeared to exhibit this behaviour for us, and 1.5.1 resolved it.
    WFM.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Alec at Apr 15, 2011 at 7:17 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Updated by: alec@alec.pl
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    -Status: Feedback
    +Status: Critical
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    -Status: Feedback
    +Status: Critical



    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-14 22:21:38] blueyed

    The problem here is quite trivial: a timeout of 0 seconds will (set via
    Net_SMTP::setTimeout => Net_Socket::setTimeout => socket_set_timeout)
    will make the socket time out after 0 seconds, which means "nearly
    instantly" and will only happen with a large amount of data.

    I've attached a patch to change the default timeout to 30 seconds
    instead.

    Even when "0" would have meant "never" here, it would not have been a
    good default.

    The problem however is two-fold, because Net_Socket does not properly
    catch the timeout, and no error is returned in that case. I will submit
    a patch for Net_Socket, too (see bug #18281)
    Given that patch for Net_Socket and a timeout of 0, you would get an
    error instead (for a "larger amount of data").

    ------------------------------------------------------------------------

    [2011-04-13 18:10:15] grosjo

    Hi,

    I am very interested in fixing this issue , using RoundCube and other
    softs based on this class.

    Please let me know if I can help in some way.
    Thanks
    Joan

    ------------------------------------------------------------------------

    [2011-04-13 09:54:20] alec

    Because Roundcube webmail users complain about similiar issue I'll try
    to help. 1.5.1 is still a problem. I feel it can be related to
    http://pear.php.net/bugs/bug.php?id=18262 and
    http://bugs.php.net/bug.php?id=39598

    I don't know how to reproduce this, but can imagine that socket's
    fwrite() (in socket's write() method) returns 0. In this case _send()
    doesn't return error and data() will continue the loop over all chunks
    of data. Final _send("\r\n.\r\n") can also not return an error.

    It looks that we could detect "0" response from write(), then sleep for
    some short time and try again. I don't know how it can be related to
    socket timeout. Maybe fwrite returns 0 after timeout is reached or sth
    or it's an other issue.

    ------------------------------------------------------------------------

    [2011-03-30 12:06:52] passembk

    I don't know if this is helpful, but I installed xdebug to trace the
    problem. Here is the relevant output:

    The first trace shows what happened when the e-mail got through without
    being cut off:
    0,6897 18185088 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18310152 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18185088 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18185184 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18185184 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18185184 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 124991
    => 124991
    The second trace shows what happend when the same e-mail was cut off:
    0,6897 18109824 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18234888 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18109824 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18109920 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18109920 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18109920 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 65536
    => 65536
    Additionally, the fwrite function generated the following notice:
    fwrite(): send of 8192 bytes failed with errno=11 Resource temporarily
    unavailable in /usr/share/php/Net/Socket.php on line 384

    ------------------------------------------------------------------------

    [2011-03-28 16:55:37] jon

    -Status: Assigned
    +Status: Feedback
    The attached patch changed the behavior to only set the socket timeout
    if a
    connection timeout was specified. That effectively removes all
    non-default timeout
    behavior, which is not the goal of the feature.

    In its default mode, the current 1.5.1 code should default to an
    infinite socket timeout
    (timeout = 0).

    So I'm a little confused what's causing the problematic behavior (an
    overly-short
    timeout that's tearing down the connection for large transfers).

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Alec at Apr 15, 2011 at 8:52 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Updated by: alec@alec.pl
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    Status: Critical
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    I was digging deeper. It looks that following is true:
    1. fsockopen()'s timeout is only for connection (just check php manual)
    2. stream_set_timeout(0) doesn't reset nor disable timeout.

    If so, we need more changes in Socket package and one simple fix for
    Net_SMTP. See patch timeout.patch. There's still a question about
    handling zero response from Socket's write() method. See my previous
    comment.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-15 08:18:56] alec

    -Status: Feedback
    +Status: Critical


    ------------------------------------------------------------------------

    [2011-04-14 22:21:38] blueyed

    The problem here is quite trivial: a timeout of 0 seconds will (set via
    Net_SMTP::setTimeout => Net_Socket::setTimeout => socket_set_timeout)
    will make the socket time out after 0 seconds, which means "nearly
    instantly" and will only happen with a large amount of data.

    I've attached a patch to change the default timeout to 30 seconds
    instead.

    Even when "0" would have meant "never" here, it would not have been a
    good default.

    The problem however is two-fold, because Net_Socket does not properly
    catch the timeout, and no error is returned in that case. I will submit
    a patch for Net_Socket, too (see bug #18281)
    Given that patch for Net_Socket and a timeout of 0, you would get an
    error instead (for a "larger amount of data").

    ------------------------------------------------------------------------

    [2011-04-13 18:10:15] grosjo

    Hi,

    I am very interested in fixing this issue , using RoundCube and other
    softs based on this class.

    Please let me know if I can help in some way.
    Thanks
    Joan

    ------------------------------------------------------------------------

    [2011-04-13 09:54:20] alec

    Because Roundcube webmail users complain about similiar issue I'll try
    to help. 1.5.1 is still a problem. I feel it can be related to
    http://pear.php.net/bugs/bug.php?id=18262 and
    http://bugs.php.net/bug.php?id=39598

    I don't know how to reproduce this, but can imagine that socket's
    fwrite() (in socket's write() method) returns 0. In this case _send()
    doesn't return error and data() will continue the loop over all chunks
    of data. Final _send("\r\n.\r\n") can also not return an error.

    It looks that we could detect "0" response from write(), then sleep for
    some short time and try again. I don't know how it can be related to
    socket timeout. Maybe fwrite returns 0 after timeout is reached or sth
    or it's an other issue.

    ------------------------------------------------------------------------

    [2011-03-30 12:06:52] passembk

    I don't know if this is helpful, but I installed xdebug to trace the
    problem. Here is the relevant output:

    The first trace shows what happened when the e-mail got through without
    being cut off:
    0,6897 18185088 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18310152 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18185088 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18185184 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18185184 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18185184 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 124991
    => 124991
    The second trace shows what happend when the same e-mail was cut off:
    0,6897 18109824 -> Net_SMTP->_send($data = '...')
    /usr/share/php/Net/SMTP.php:1036
    0,6897 18234888 -> Net_SMTP->_debug($message =
    '...') /usr/share/php/Net/SMTP.php:250
    0,6897 18109824 -> Net_Socket->write($data = '...',
    $blocksize = ???) /usr/share/php/Net/SMTP.php:252
    0,6897 18109920 -> is_resource(resource(108) of
    type (stream)) /usr/share/php/Net/Socket.php:379
    => TRUE
    0,6897 18109920 -> is_null(NULL)
    /usr/share/php/Net/Socket.php:383
    => TRUE
    0,6897 18109920 -> fwrite(resource(108) of type
    (stream), '...') /usr/share/php/Net/Socket.php:384
    => 65536
    => 65536
    Additionally, the fwrite function generated the following notice:
    fwrite(): send of 8192 bytes failed with errno=11 Resource temporarily
    unavailable in /usr/share/php/Net/Socket.php on line 384

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Jon at Apr 15, 2011 at 1:43 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Updated by: jon@php.net
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    -Status: Critical
    +Status: Closed
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    -Status: Critical
    +Status: Closed
    I've patched the Net_SMTP code to avoid setting the timeout value to 0.
    I mistakenly
    thought "zero" implied "infinite" there, probably because that's what
    the current
    Net_Socket code appears to believe.

    I'm not going to apply the Net_Socket patch at this time because I'm not
    the
    Net_Socket maintainer.

    I'll wait for someone to verify that the code in just checked in to SVN
    (revision
    310236) fixes the reported problem before I release a new version of the
    package.
    Please give it a try if you have the time.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-15 09:54:41] alec

    Added #patch bug:18335;patch:timeout.patch;revision:1302861281;.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:20] alec

    I was digging deeper. It looks that following is true:
    1. fsockopen()'s timeout is only for connection (just check php manual)
    2. stream_set_timeout(0) doesn't reset nor disable timeout.

    If so, we need more changes in Socket package and one simple fix for
    Net_SMTP. See patch timeout.patch. There's still a question about
    handling zero response from Socket's write() method. See my previous
    comment.

    ------------------------------------------------------------------------

    [2011-04-15 08:18:56] alec

    -Status: Feedback
    +Status: Critical


    ------------------------------------------------------------------------

    [2011-04-14 22:21:38] blueyed

    The problem here is quite trivial: a timeout of 0 seconds will (set via
    Net_SMTP::setTimeout => Net_Socket::setTimeout => socket_set_timeout)
    will make the socket time out after 0 seconds, which means "nearly
    instantly" and will only happen with a large amount of data.

    I've attached a patch to change the default timeout to 30 seconds
    instead.

    Even when "0" would have meant "never" here, it would not have been a
    good default.

    The problem however is two-fold, because Net_Socket does not properly
    catch the timeout, and no error is returned in that case. I will submit
    a patch for Net_Socket, too (see bug #18281)
    Given that patch for Net_Socket and a timeout of 0, you would get an
    error instead (for a "larger amount of data").

    ------------------------------------------------------------------------

    [2011-04-13 18:10:15] grosjo

    Hi,

    I am very interested in fixing this issue , using RoundCube and other
    softs based on this class.

    Please let me know if I can help in some way.
    Thanks
    Joan

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Mail at Apr 15, 2011 at 7:16 pm
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Comment by: mail@dunix-data.de
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    Status: Closed
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    Revision 310236 fixed the problem for me.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-15 14:44:40] jon

    -Status: Critical
    +Status: Closed
    I've patched the Net_SMTP code to avoid setting the timeout value to 0.
    I mistakenly
    thought "zero" implied "infinite" there, probably because that's what
    the current
    Net_Socket code appears to believe.

    I'm not going to apply the Net_Socket patch at this time because I'm not
    the
    Net_Socket maintainer.

    I'll wait for someone to verify that the code in just checked in to SVN
    (revision
    310236) fixes the reported problem before I release a new version of the
    package.
    Please give it a try if you have the time.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:41] alec

    Added #patch bug:18335;patch:timeout.patch;revision:1302861281;.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:20] alec

    I was digging deeper. It looks that following is true:
    1. fsockopen()'s timeout is only for connection (just check php manual)
    2. stream_set_timeout(0) doesn't reset nor disable timeout.

    If so, we need more changes in Socket package and one simple fix for
    Net_SMTP. See patch timeout.patch. There's still a question about
    handling zero response from Socket's write() method. See my previous
    comment.

    ------------------------------------------------------------------------

    [2011-04-15 08:18:56] alec

    -Status: Feedback
    +Status: Critical


    ------------------------------------------------------------------------

    [2011-04-14 22:21:38] blueyed

    The problem here is quite trivial: a timeout of 0 seconds will (set via
    Net_SMTP::setTimeout => Net_Socket::setTimeout => socket_set_timeout)
    will make the socket time out after 0 seconds, which means "nearly
    instantly" and will only happen with a large amount of data.

    I've attached a patch to change the default timeout to 30 seconds
    instead.

    Even when "0" would have meant "never" here, it would not have been a
    good default.

    The problem however is two-fold, because Net_Socket does not properly
    catch the timeout, and no error is returned in that case. I will submit
    a patch for Net_Socket, too (see bug #18281)
    Given that patch for Net_Socket and a timeout of 0, you would get an
    error instead (for a "larger amount of data").

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Alec at Apr 17, 2011 at 8:32 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Updated by: alec@alec.pl
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    Status: Closed
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    @jon: what about my thoughts on handling "0" result from Socket's
    write()? I think it should be at least considered as a write error.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-15 20:17:43] passembk

    Revision 310236 fixed the problem for me.

    ------------------------------------------------------------------------

    [2011-04-15 14:44:40] jon

    -Status: Critical
    +Status: Closed
    I've patched the Net_SMTP code to avoid setting the timeout value to 0.
    I mistakenly
    thought "zero" implied "infinite" there, probably because that's what
    the current
    Net_Socket code appears to believe.

    I'm not going to apply the Net_Socket patch at this time because I'm not
    the
    Net_Socket maintainer.

    I'll wait for someone to verify that the code in just checked in to SVN
    (revision
    310236) fixes the reported problem before I release a new version of the
    package.
    Please give it a try if you have the time.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:41] alec

    Added #patch bug:18335;patch:timeout.patch;revision:1302861281;.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:20] alec

    I was digging deeper. It looks that following is true:
    1. fsockopen()'s timeout is only for connection (just check php manual)
    2. stream_set_timeout(0) doesn't reset nor disable timeout.

    If so, we need more changes in Socket package and one simple fix for
    Net_SMTP. See patch timeout.patch. There's still a question about
    handling zero response from Socket's write() method. See my previous
    comment.

    ------------------------------------------------------------------------

    [2011-04-15 08:18:56] alec

    -Status: Feedback
    +Status: Critical


    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335
  • Jon at Apr 26, 2011 at 4:50 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18335&edit=1

    ID: 18335
    Updated by: jon@php.net
    Reported By: dunix at gmx dot de
    Summary: Attachments broken
    Status: Closed
    Type: Bug
    Package: Net_SMTP
    Operating System: Gentoo Linux
    Package Version: 1.5.1
    PHP Version: 5.3.5
    Assigned To: jon
    Roadmap Versions:
    New Comment:

    0-byte socket write() results will be considered a failure in the next
    release.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-04-17 09:33:58] alec

    @jon: what about my thoughts on handling "0" result from Socket's
    write()? I think it should be at least considered as a write error.

    ------------------------------------------------------------------------

    [2011-04-15 20:17:43] passembk

    Revision 310236 fixed the problem for me.

    ------------------------------------------------------------------------

    [2011-04-15 14:44:40] jon

    -Status: Critical
    +Status: Closed
    I've patched the Net_SMTP code to avoid setting the timeout value to 0.
    I mistakenly
    thought "zero" implied "infinite" there, probably because that's what
    the current
    Net_Socket code appears to believe.

    I'm not going to apply the Net_Socket patch at this time because I'm not
    the
    Net_Socket maintainer.

    I'll wait for someone to verify that the code in just checked in to SVN
    (revision
    310236) fixes the reported problem before I release a new version of the
    package.
    Please give it a try if you have the time.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:41] alec

    Added #patch bug:18335;patch:timeout.patch;revision:1302861281;.

    ------------------------------------------------------------------------

    [2011-04-15 09:54:20] alec

    I was digging deeper. It looks that following is true:
    1. fsockopen()'s timeout is only for connection (just check php manual)
    2. stream_set_timeout(0) doesn't reset nor disable timeout.

    If so, we need more changes in Socket package and one simple fix for
    Net_SMTP. See patch timeout.patch. There's still a question about
    handling zero response from Socket's write() method. See my previous
    comment.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=18335

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedApr 13, '11 at 8:52a
activeApr 26, '11 at 4:50a
posts9
users4
websitepear.php.net

4 users in discussion

Alec: 4 posts Jon: 2 posts Mail: 2 posts Grosjo: 1 post

People

Translate

site design / logo © 2022 Grokbase