Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ftplib does not honour "timeout" parameter for active data connections #49064

Closed
giampaolo opened this issue Jan 3, 2009 · 6 comments
Closed
Assignees
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@giampaolo
Copy link
Contributor

BPO 4814
Nosy @pitrou, @vstinner, @giampaolo, @bitdancer
Files
  • ftplib.patch: Modified patch which invokes settimeout() before accept()
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/giampaolo'
    closed_at = <Date 2010-04-19.22:30:45.390>
    created_at = <Date 2009-01-03.00:52:13.680>
    labels = ['type-bug', 'library']
    title = 'ftplib does not honour "timeout" parameter for active data connections'
    updated_at = <Date 2010-04-19.22:30:45.388>
    user = 'https://github.com/giampaolo'

    bugs.python.org fields:

    activity = <Date 2010-04-19.22:30:45.388>
    actor = 'giampaolo.rodola'
    assignee = 'giampaolo.rodola'
    closed = True
    closed_date = <Date 2010-04-19.22:30:45.390>
    closer = 'giampaolo.rodola'
    components = ['Library (Lib)']
    creation = <Date 2009-01-03.00:52:13.680>
    creator = 'giampaolo.rodola'
    dependencies = []
    files = ['12643']
    hgrepos = []
    issue_num = 4814
    keywords = ['patch']
    message_count = 6.0
    messages = ['78912', '79390', '79392', '97061', '97095', '103650']
    nosy_count = 4.0
    nosy_names = ['pitrou', 'vstinner', 'giampaolo.rodola', 'r.david.murray']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue4814'
    versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2']

    @giampaolo
    Copy link
    Contributor Author

    When using the optional ftplib.FTP()'s timeout parameter which
    specifies a timeout in seconds for blocking operations like the
    connection attempt, it is applied on both FTP control and passive data
    channel (if any).
    It is not applied for active (PORT/EPRT) data connections.
    The patch in attachment modifies ftplib so that when ntransfer method
    is called in active mode, timeout is applied on the resulting data
    connection.

    @vstinner
    Copy link
    Member

    vstinner commented Jan 8, 2009

    Your patch looks correct.

    @giampaolo
    Copy link
    Contributor Author

    I'm sorry, I realized right now that settimeout() should be used also
    *before* invoking accept(), to avoid the client to stall in case the
    server does not establish any connection.
    The second patch in attachment does that by using settimeout() straight
    into FTP.makeport() method.

    @pitrou
    Copy link
    Member

    pitrou commented Dec 30, 2009

    This looks good, of course. Perhaps you want to add a test, if it isn't
    too difficult to do so.

    @giampaolo
    Copy link
    Contributor Author

    This time it's not easy as I see no way to distinguish whether the
    timeout exception gets raised by the command or the control socket, as
    makeport() method implementation deals with both:

    <snippet>
    host = self.sock.getsockname()[0]
    if self.af == socket.AF_INET:
    resp = self.sendport(host, port) # socket.timeout can be
    raised here
    else:
    resp = self.sendeprt(host, port) # ...here
    if self.timeout is not _GLOBAL_DEFAULT_TIMEOUT:
    sock.settimeout(self.timeout) # or here
    </snippet>

    I think the best we can do is add a test which checks the timeout
    applied to the data socket resulting from a PASV/PORT request.
    That doesn't cover this specific bug at all but it's something which is
    currently missing and that it would be nice to have.

    @giampaolo giampaolo self-assigned this Apr 17, 2010
    @giampaolo
    Copy link
    Contributor Author

    Fixed as r80226 (2.7) and r80228 (3.2).

    @giampaolo giampaolo added the stdlib Python modules in the Lib dir label Apr 19, 2010
    @giampaolo giampaolo added the type-bug An unexpected behavior, bug, or error label Apr 19, 2010
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants