From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 18:14:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7A2E16A402; Thu, 29 Mar 2007 18:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2A38513C44B; Thu, 29 Mar 2007 18:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2TIEc4q046603; Thu, 29 Mar 2007 13:14:38 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 29 Mar 2007 14:14:14 -0400 User-Agent: KMail/1.9.6 References: <460AE39B.4070706@root.org> <460BFD1D.9000402@fnop.net> In-Reply-To: <460BFD1D.9000402@fnop.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703291414.15452.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 29 Mar 2007 13:14:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2961/Thu Mar 29 09:06:01 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Rui Paulo , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , current@freebsd.org, Nate Lawson Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:14:47 -0000 On Thursday 29 March 2007 01:53:33 pm Rui Paulo wrote: > Nate Lawson wrote: > > To speed up pkg_add and other ftp command channel performance over slow > > links, change this: > > [...] > > All ftp servers I've ever seen support a full path when changing down > > dirs. This might be a DOS ftp server thing however. In any case, if > > there is an error to the all-in-one CWD, the code reverts back to legacy > > behavior of multiple CWDs. >=20 > Yes, I think this behavior is acceptable. If the pathname fails it only=20 > adds one more CWD, but reduces the time on the successful cases (which=20 > are many if you consider the Ports collection). >=20 > Dag-Erling Sm=F8rgrav wrote: > > No. This is a violation of the FTP protocol. > > [...] > > When the all-in-one CWD fails, you're SOL. You have no idea what > > state the server is in, and you have to start over. >=20 > About the possible violation of the RFC, I quote: >=20 > pathname >=20 > Pathname is defined to be the character string which must be > input to a file system by a user in order to identify a file. > Pathname normally contains device and/or directory names, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > file name specification. FTP does not yet specify a standard > ^^^^^^^^^^^^^^^^^^^^^^^ > pathname convention. Each user must follow the file naming > conventions of the file systems involved in the transfer. >=20 >=20 > CHANGE WORKING DIRECTORY (CWD) >=20 > This command allows the user to work with a different > directory or dataset for file storage or retrieval without > altering his login or accounting information. Transfer > parameters are similarly unchanged. The argument is a > pathname specifying a directory or other system dependent > ^^^^^^^^ > file group designator. >=20 >=20 > I'm not sure why you consider this a violation of the protocol. > Also, considering the reply codes to the CWD command, only 421 seems to=20 > change the server state. >=20 > Have you seen servers that change their state by issuing giving invalid=20 > arguments to the CWD command ? http://www.freebsd.org/cgi/query-pr.cgi?pr=3D83278 In this case IIRC, the problem was the leading / as the path fetched was=20 supposed to be relative to the user's home directory, but instead fetch sen= t=20 an absolute path and failed. See also http://www.ietf.org/rfc/rfc1738.txt which is the RFC for URLs and= =20 explains exactly how the for ftp URLs should be interpreted: 3.2.2. FTP url-path The url-path of a FTP URL has the following syntax: //...//;type=3D Where through and are (possibly encoded) strings and is one of the characters "a", "i", or "d". The part ";type=3D" may be omitted. The and parts may be empty. The whole url-path may be omitted, including the "/" delimiting it from the prefix containing user, password, host, and port. The url-path is interpreted as a series of FTP commands as follows: Each of the elements is to be supplied, sequentially, as the argument to a CWD (change working directory) command. If the typecode is "d", perform a NLST (name list) command with as the argument, and interpret the results as a file directory listing. Otherwise, perform a TYPE command with as the argument, and then access the file whose name is (for example, using the RETR command.) Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". For example, the URL is interpreted by FTP-ing to "host.dom", logging in as "myname" (prompting for a password if it is asked for), and then executing "CWD /etc" and then "RETR motd". This has a different meaning from which would "CWD etc" and then "RETR motd"; the initial "CWD" might be executed relative to the default directory for "myname". On the other hand, , would "CWD " with a null argument, then "CWD etc", and then "RETR motd". =2D-=20 John Baldwin