Re: [ftpext] 1st post; miscellaneous FTP additions.

Daniel Stenberg <> Sun, 07 November 2010 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 688843A6884 for <>; Sun, 7 Nov 2010 10:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.249
X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cPXQRQ2V5ce2 for <>; Sun, 7 Nov 2010 10:29:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CF7AF3A688E for <>; Sun, 7 Nov 2010 10:29:14 -0800 (PST)
Received: from ( []) by (8.14.3/8.14.3/Debian-9.1) with ESMTP id oA7ITXXB026098; Sun, 7 Nov 2010 19:29:33 +0100
Date: Sun, 07 Nov 2010 19:29:33 +0100
From: Daniel Stenberg <>
In-Reply-To: <058201cb7dfc$4bd03d00$e370b700$@com>
Message-ID: <>
References: <058201cb7dfc$4bd03d00$e370b700$@com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 ( []); Sun, 07 Nov 2010 19:29:33 +0100 (CET)
Subject: Re: [ftpext] 1st post; miscellaneous FTP additions.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Nov 2010 18:29:16 -0000

On Sat, 6 Nov 2010, Alun Jones wrote:

> c.       To address storage security of transferred files, it may be
> appropriate to add commands and responses for the following cases:

I must say that I'm very skeptical about such peculiar and specific commands, 
and if you want to move ahead and suggest those they should be in a separate 
draft imho.

> 4.  Keeping firewalls open through long data transfers can adequately be 
> achieved using the NOOP command at regular intervals, or if that command is 
> not supported, the STAT command, which is already documented to give a 
> user-readable status during a data transfer.

Sorry, but I've tried this and it turned out that is not a reliable way to 
keep a connection alive. Several FTP server implementations just don't read 
the control connection while the data is being transfered.

We got better functionality by simply using the TCP KEEPALIVE option and 
setting the timers small enough (on the systems that allow that sort of 

> 5.       GSSAPI FTP as defined in RFC 2228 should be deprecated, as it does
> not provide for separate encryption contexts between the command and data
> ports - because they share an encryption context, if a command is sent
> during a transfer, the synchronization is lost, and all further data and
> commands are garbled and unreadable.

We can't just deprecate it because it one or more flaws if there are still 
users of that protocol in the wild. Can we?

> 6.       FTP URIs don't work as documented. I have yet to see a single
> client implementation that treats "" as an invitation
> to connect to and issue the "CWD foo" command - they all issue
> "CWD /foo".

What are you talking about? curl has done "CWD foo" since 1998 and I would 
strongly disagree to changing that URI definition at this point.

If I remember things correctly, there's a flaw in how empty path parts are 
supposed to be handled, as in