tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PR 43133 should be closed



>> So, there may be a client-side bug involved (if the client ignores
>> the parenthetical note) or a server-side bug (if not).  I'd have to
>> snoop the protocol to be certain.

> The issue I'm seeing is that the server simply defaults to being in
> BINARY mode, without the client requesting that, which I think is not
> in compliance with the RFC

You are correct, at least according to 959: "The default representation
type is ASCII Non-print.".  But is your "without the client requesting
that" based on user actions, or protocol snooping?  I've seen FTP
clients that, by default, do a SYST and then, for some returned strings
(including almost everything extant today), switch to TYPE I.

> [W]hat's more, I don't recall any method by which the client can
> ascertain which mode the server is in.

959 specifies a STAT command.  Its response is not precisely specified;
959 says

            If no argument is given, the server should return general
            status information about the server FTP process.  This
            should include current values of all transfer parameters and
            the status of connections.

which would probably be s/should/SHOULD/ today.  I just tried it from
1.4T client to 5.2 server, and command-line "stat" prints client-cached
data (it does not generate any protocol traffic), but "quote STAT"
works, and, for my test connection, resulted in

ftp> quote STAT
---> STAT
211-Guest login
 TYPE A N
 STRU F
 MODE S
 No transfer
211 End
ftp> 

> Right now I see nothing needing fixing (or not in this area).

I am inclined to agree.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index