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
-> "sick".

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
of time).

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-
less request).

--rafal

----
Rafal Boni                                                     rafal@pobox.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill