Subject: Re: tnftp and HTTP cookies
To: Ignatios Souvatzis <firstname.lastname@example.org>
From: Rafal Boni <email@example.com>
Date: 12/22/2003 21:24:24
In message <20031216080745.GA5772@cs.uni-bonn.de>, you write:
-> On Sat, Dec 13, 2003 at 08:44:04PM +0100, Klaus Heinz wrote:
-> > Hi,
-> > /usr/bin/ftp (tnftp) cannot retrieve=20
-> > http://rapidsvn.tigris.org/files/documents/341/8734/rapidsvn-0.4.0.tar.gz
-> > due to the use of HTTP cookies.
-> > So far this has been the only URL where I
-> > have seen this and I wonder whether people would be interested in cookie
-> > support (RFC 2109) for tnftp.
-> Well, this is a last-century-viewpoint, but....
-> Using http instead of ftp for bulk data transfer is sort-of-strange.
-> Using cookies for http bulk data transfers makes me want to call this
I actually find it quite useful, esp. in places with broken Checkpoint
firewalls (ftp.netbsd.org is bitten by this one unless one turns off
the post-login message) and other baroque network setups/policies.
Besides, for one-off file retrieval, http has the advantage of only a
single connection setup vs. multiple (which makes a big difference if
a site hosts a busy ftp/http server on the same box... I remember how
slow RFC retrieval was from rfc-editor.org's ftp server when they only
allowed FTP downloads; the connection setup took a significant chunk
If you accept that http downloads are a win, then cookied transfers
do make some sense, though certainly not for publicly-available files.
If you ask me whether it makes sense to put this into ftp(1), then I
have another answer, though.
As for just just accepting the cookies and /dev/null'ing them, that
adds no value (the ftp client already does this by virtue of the fact
that it ignores the cookie headers -- you need to return the cookies
to the server, else you'd be able to download with a totally-cookie-
Rafal Boni firstname.lastname@example.org
We are all worms. But I do believe I am a glowworm. -- Winston Churchill