From toasty@temphost.dragondata.com  Wed Jan 31 12:16:07 2001
Return-Path: <toasty@temphost.dragondata.com>
Received: from temphost.dragondata.com (temphost.dragondata.com [63.167.131.128])
	by hub.freebsd.org (Postfix) with ESMTP id 756AB37B699
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 31 Jan 2001 12:16:06 -0800 (PST)
Received: (from root@localhost)
	by temphost.dragondata.com (8.9.3/8.9.3) id OAA39582;
	Wed, 31 Jan 2001 14:16:36 -0600 (CST)
	(envelope-from toasty)
Message-Id: <200101312016.OAA39582@temphost.dragondata.com>
Date: Wed, 31 Jan 2001 14:16:36 -0600 (CST)
From: toasty@dragondata.com
Reply-To: toasty@dragondata.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: ftpd not RFC compliant?
X-Send-Pr-Version: 3.2

>Number:         24757
>Category:       bin
>Synopsis:       ftpd(8) not RFC compliant
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 31 12:20:00 PST 2001
>Closed-Date:    Tue Jul 10 03:30:02 UTC 2012
>Last-Modified:  Tue Jul 10 03:30:02 UTC 2012
>Originator:     Kevin Day
>Release:        FreeBSD 4.2-RELEASE i386
>Organization:
Ikadega
>Environment:

4.2-RELEASE ftpd

>Description:

According to rfc959:

 
          STORE UNIQUE (STOU)
 
             This command behaves like STOR except that the resultant
             file is to be created in the current directory under a name
             unique to that directory.  The 250 Transfer Started response
             must include the name generated.


The FreeBSD ftpd does not return 250:


---> EPSV
229 Entering Extended Passive Mode (|||53363|)
---> STOU temp
150 Opening BINARY mode data connection for 'temp.1'.
100% |******************************************************************************************************| 79129       00:00 ETA
226 Transfer complete (unique file name:temp.1).
79129 bytes sent in 0.02 seconds (3.55 MB/s)



That is kinda vague. Does that imply that 250 must be returned if you STOU,
or that if you *do* return a 250, you must include the name?


>How-To-Repeat:


>Fix:



>Release-Note:
>Audit-Trail:

From: Yar Tikhiy <yar@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, toasty@dragondata.com
Cc:  
Subject: Re: bin/24757: ftpd not RFC compliant
Date: Tue, 30 Jul 2002 15:20:23 +0400

 I believe there is a typo in RFC 959 there.  The 250 responce cannot
 mean "Transfer started" since it should be issued after a transfer
 has been *finished* (without closing the data connection.)  I'm
 almost sure it must be the 150 responce there.  The FreeBSD ftpd
 has went even further, including the unique name into both leading
 (150) and trailing (226, transfer finished and data channel closed)
 responces.  Thus I think this PR can be closed if you don't mind.
 
 -- 
 Yar
Responsible-Changed-From-To: freebsd-bugs->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Thu Aug 1 03:38:39 PDT 2002 
Responsible-Changed-Why:  
To not forget about this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=24757 

From: "Yar Tikhiy" <yar@FreeBSD.org>
To: <freebsd-gnats-submit@FreeBSD.org>, <toasty@dragondata.com>
Cc:  
Subject: Re: bin/24757: ftpd not RFC compliant
Date: Tue, 6 Aug 2002 16:32:55 +0400

 By the way, RFC 1123 explicitly says that the RFC 959 statement
 on the 250 responce to STOU is erroneous.  However, RFC 1123
 specifies a format for the 150 reply to STOU that differs from ours.
 So let this PR be open until the 150 reply to STOU is fixed in our ftpd(8).
 

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/24757: ftpd not RFC compliant
Date: Mon, 23 Apr 2007 20:45:16 +0400

 For the record:
 
 BSD-derived ftpd servers including the stock ftpd(8) from FreeBSD
 and tnftpd from NetBSD issue a 150 reply _after_ they established
 the data connection.  According to RFC 959, the 150 reply is to
 indicate that the file was opened OK and the data connection is
 about to be established.  I.e., the 150 reply should be send just
 _before_ opening the data connection.  FTP clients even include
 workarounds for this kind of a bug, with BSD ftp(1) not being an
 exception.  The wrong behaviour dates back to rather old days, and
 it may be dangerous to change it.
 
 -- 
 Yar
State-Changed-From-To: open->closed 
State-Changed-By: eadler 
State-Changed-When: Tue Jul 10 03:30:01 UTC 2012 
State-Changed-Why:  
per yar@ 

http://www.freebsd.org/cgi/query-pr.cgi?pr=24757 
>Unformatted:
