From nordquis@visi.com  Wed Dec 17 20:44:15 1997
Received: from mixer.visi.com (root@mixer.visi.com [204.73.178.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA16843
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 17 Dec 1997 20:39:37 -0800 (PST)
          (envelope-from nordquis@visi.com)
Received: from thumper.visi.com (nordquis@[209.98.98.3] (may be forged)) by mixer.visi.com (8.8.6/8.7.5) with ESMTP id WAA04815 for <FreeBSD-gnats-submit@freebsd.org>; Wed, 17 Dec 1997 22:18:36 -0600 (CST)
Received: (from nordquis@localhost) by thumper.visi.com (8.8.5/8.6.12) id WAA08221 for FreeBSD-gnats-submit@freebsd.org; Wed, 17 Dec 1997 22:18:35 -0600 (CST)
Message-Id: <199712180418.WAA08221@thumper.visi.com>
Date: Wed, 17 Dec 1997 22:18:35 -0600 (CST)
From: "Brent J. Nordquist" <bjn@visi.com>
Reply-To: "Brent J. Nordquist" <bjn@visi.com>
To: FreeBSD-gnats-submit@freebsd.org
Subject: RFC1738 changes to fetch break non-anonymous FTP
X-Send-Pr-Version: 3.2

>Number:         5333
>Category:       bin
>Synopsis:       RFC1738 changes to fetch break non-anonymous FTP
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    fenner
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 17 20:50:00 PST 1997
>Closed-Date:    Thu Dec 18 08:38:26 PST 1997
>Last-Modified:  Thu Dec 18 08:41:47 PST 1997
>Originator:     Brent J. Nordquist
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
None
>Environment:

	Affects (tested on) 3.0-CURRENT-971208 and 2.2-STABLE-971212
	against ftpd on Solaris 2.5.1, SunOS 4.1.4, and UnixWare.

>Description:

	The recent changes to usr.bin/fetch/ftp.c (1.8&9 and 1.3.2.4&5)
	cause non-anonymous FTP fetches to fail.

>How-To-Repeat:

	When FTP_LOGIN and FTP_PASSWORD are set, the two forms
	(ftp://host/path/to/file.txt and -h host -c path/to -f file.txt)
	both result in the same error:

fetch: host: path: File unavailable (e.g., file not found, no access)

	Note that the third error token ("path") is the first component;
	this is suspiciously similar to the change description for rev
	1.8.  A regular ftp command with the same login, password, path,
	and file works fine.

>Fix:
	
	Reverting to rev 1.7 or 1.3.2.3 fixes the problem.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->fenner 
Responsible-Changed-By: fenner 
Responsible-Changed-When: Wed Dec 17 22:17:16 PST 1997 
Responsible-Changed-Why:  
fenner made the changes in question 

From: Bill Fenner <fenner@parc.xerox.com>
To: "Brent J. Nordquist" <bjn@visi.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/5333: RFC1738 changes to fetch break non-anonymous FTP 
Date: Wed, 17 Dec 1997 22:16:29 PST

 Can you please follow up with the output of 'fetch -v'?  I tried your
 example (admittedly, against a FreeBSD ftpd, but...) and had no trouble:
 
 ampere% fetch -v ftp://ampere.freebsd.org/public_html/test.html
 Sending: USER fenner
 ampere.freebsd.org FTP server (Version 6.00) ready.
 Password required for fenner.
 Sending: PASS xxx
 User fenner logged in.
 Sending: TYPE I
 Type set to I.
 Sending: CWD public_html
 CWD command successful.
 Sending SIZE test.html
 1508
 Sending MDTM test.html
 19960112053431
 Sending: PORT 204,216,27,20,4,70
 PORT command successful.
 Sending: RETR test.html
 Opening BINARY mode data connection for 'test.html' (1508 bytes).
 Receiving test.html (1508 bytes)Sending: QUIT
 Transfer complete.
 Goodbye.
 Receiving test.html (1508 bytes): 100%
 1508 bytes transfered in 0.0 seconds  (63.98 Kbytes/s)
 
 Are you sure that your URL is relative to FTP_USER's home directory?
 
   Bill

From: "Brent J. Nordquist" <bjn@visi.com>
To: fenner@parc.xerox.com (Bill Fenner)
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/5333: RFC1738 changes to fetch break non-anonymous FTP
Date: Thu, 18 Dec 1997 09:09:43 -0600 (CST)

 | Can you please follow up with the output of 'fetch -v'?  I tried your
 | example (admittedly, against a FreeBSD ftpd, but...) and had no trouble:
 | 
 | Are you sure that your URL is relative to FTP_USER's home directory?
 
 Well, you went right to the heart of the issue!  I was using the second
 form (-f) with an absolute path (not a relative one), and the 1.7
 fetch.c produces:
 
 ---cut here---
 Sending: USER devel
 asia FTP server (UNIX_SV 2.1.2) ready.
 Password required for devel.
 Sending: PASS xxx
 User devel logged in.
 Sending: TYPE I
 Type set to I.
 Sending SIZE /var/local/rc5/rc5.log
 304576
 Sending MDTM /var/local/rc5/rc5.log
 19971218143909
 Sending: PORT 192,168,105,177,5,100
 PORT command successful.
 Sending: RETR /var/local/rc5/rc5.log
 Opening BINARY mode data connection for /var/local/rc5/rc5.log (304576 bytes).
 Receiving asia.log (304576 bytes)Sending: QUIT
 Transfer complete.
 Goodbye.
 
 304576 bytes transfered in 0.5 seconds  (542.51 Kbytes/s)
 ---cut here---
 
 i.e., it "just works".  I have no idea if this is "legal" or not, but
 the real FTP lets you give an absolute path this way too.  Anyway, the
 1.9 fetch.cc with the same command gives:
 
 ---cut here---
 Sending: USER devel
 asia FTP server (UNIX_SV 2.1.2) ready.
 Password required for devel.
 Sending: PASS xxx
 User devel logged in.
 Sending: TYPE I
 Type set to I.
 Sending: CWD var
 var: No such file or directory.
 fetch: asia: var: File unavailable (e.g., file not found, no access)
 ---cut here---
 
 When I changed the argument to be relative to devel's home directory
 (using lots of ../'s) I was able to get the 1.9 fetch.c to work.
 
 So I guess I can make the current one work now, but it's ugly, and
 depends on knowing how many levels the user's home directory is when
 that data isn't really needed on the client side.  It seems like
 some kind of absolute path ability would be useful here.
 
 Thanks for your help in troubleshooting!
 
 -- 
 Brent J. Nordquist / bjn@visi.com
 +1 612 827-2747
State-Changed-From-To: open->closed 
State-Changed-By: fenner 
State-Changed-When: Thu Dec 18 08:38:26 PST 1997 
State-Changed-Why:  
You need to start your URL with %2F to make it absolute: 

RFC 1738            Uniform Resource Locators (URL)        December 1994 

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

(our fetch is not strictly RFC-conformant because it treats the last 2 
requests the same rather than sending an illegal FTP command) 
>Unformatted:
