Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Mar 2007 14:14:14 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        Rui Paulo <rpaulo@fnop.net>, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no>, current@freebsd.org, Nate Lawson <nate@root.org>
Subject:   Re: libfetch ftp patch for less latency
Message-ID:  <200703291414.15452.jhb@freebsd.org>
In-Reply-To: <460BFD1D.9000402@fnop.net>
References:  <460AE39B.4070706@root.org> <460BFD1D.9000402@fnop.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <url-path> for ftp URLs should be interpreted:

<quote from=3D"rfc1738">
3.2.2. FTP url-path

   The url-path of a FTP URL has the following syntax:

        <cwd1>/<cwd2>/.../<cwdN>/<name>;type=3D<typecode>

   Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
   and <typecode> is one of the characters "a", "i", or "d".  The part
   ";type=3D<typecode>" may be omitted. The <cwdx> and <name> 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 <cwd> 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
      <name> as the argument, and interpret the results as a file
      directory listing.

      Otherwise, perform a TYPE command with <typecode> as the argument,
      and then access the file whose name is <name> (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 <URL:ftp://myname@host.dom/%2Fetc/motd>; 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
   <URL:ftp://myname@host.dom/etc/motd>; 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,
   <URL:ftp://myname@host.dom//etc/motd>, would "CWD " with a null
   argument, then "CWD etc", and then "RETR motd".
</quote>

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703291414.15452.jhb>