Date: Mon, 04 Jul 2005 04:48:44 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-net@FreeBSD.org Subject: Re: Bug in libfetch handling of FTP urls.. Message-ID: <86vf3rthf7.fsf@xps.des.no> In-Reply-To: <200506281338.14511.jhb@FreeBSD.org> (John Baldwin's message of "Tue, 28 Jun 2005 13:38:13 -0400") References: <200506281338.14511.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@FreeBSD.org> writes: > Ran into this at work. Suppose I am fetching a file over ftp for a user = foo > whose home dir is /home/foo' and I want to retrieve the 'bar/baz' file ou= t of > his home directory. [...] This is tricky because libfetch caches FTP connections, so you can't always assume that CWD is ~ at the beginning of the transfer if you've already transferred something from the same host/user/password tuple in the same process. See (ironically) RFC 1738 section 3.2.5. Connection caching is an essential feature, because it has a huge impact on the speed of a network install. Although sysinstall still uses libftpio + cpio, one may hope that it will one day in the not- too-distant future switch to libfetch + libarchive. > I verified this by doing 'fetch -vv' and seeing that it does one big CWD > (instead of the multiple CWD's the RFC says should happen) and that it > includes the leading '/' when it should not. I am currently testing a patch for this. > Also, it seems that fetch ignores the ';type=3DX' optional part of the ur= l-path > and always uses TYPE I. Correct, that was never implemented. At the very least, the typecode should be stripped from the URL. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86vf3rthf7.fsf>