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