Bug 24757
| Summary: | ftpd(8) not RFC compliant | ||
|---|---|---|---|
| Product: | Base System | Reporter: | toasty <toasty> |
| Component: | bin | Assignee: | Yar Tikhiy <yar> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.2-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
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 To not forget about this PR. 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). 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 per yar@ |
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?