[prev in list] [next in list] [prev in thread] [next in thread]
List: proftpd-users
Subject: Re: [Proftpd-user] Bad behavior by FTP client results in "SIZE not
From: "Thomas L. Shinnick" <tshinnic () io ! com>
Date: 2007-09-26 8:25:58
Message-ID: 6.2.5.6.2.20070926031917.05167870 () io ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
At 01:49 AM 9/26/2007, Dariusz Pietrzak wrote:
> > 226 Transfer complete
> > ftp> quote size README.MIRRORS
> > ---> size README.MIRRORS
> > 550 SIZE not allowed in ASCII mode
> > Note that the client switches to ASCII mode to receive the output
> > from DIR, but does not reverse that.
> And that's good, otherwise you end up with windows-like behaviour like
> this:
> TYPE A
> LIST
> TYPE I
> TYPE A
> LIST
> TYPE I
> TYPE A
> LIST
> ...
>
> I see no need to reverse the mode until you're doing something that needs
>'TYPE I',
But, of course, that is really the point. The client _did_ reverse
the mode, which had been set by user request using a plain old BINARY
command. So it is really more surprising that it doesn't undo what
it just did, so as to put things back the way the user wanted them.
It is true that another sequence of commands to try would be
binary
dir
get foo
and see whether/that the client program does a "TYPE I" at that point.
>for example running SIZE, but, since you did that with QUOTE, the
>client had no way of knowing that you need the mode reversed.
And the user had no way of knowing the client was diddling the mode
behind the scenes ... :-)
>--
>Dariush Pietrzak,
[Attachment #5 (text/html)]
<html>
<body>
<font size=3>At 01:49 AM 9/26/2007, Dariusz Pietrzak wrote:<br>
<blockquote type=cite class=cite cite="">> 226 Transfer
complete<br>
> ftp> quote size README.MIRRORS<br>
> ---> size README.MIRRORS<br>
> 550 SIZE not allowed in ASCII mode<br>
> Note that the client switches to ASCII mode to receive the output
<br>
> from DIR, but does not reverse that.<br>
And that's good, otherwise you end up with windows-like behaviour
like<br>
this:<br>
TYPE A<br>
LIST<br>
TYPE I<br>
TYPE A<br>
LIST<br>
TYPE I<br>
TYPE A<br>
LIST<br>
...<br><br>
I see no need to reverse the mode until you're doing something that
needs<br>
'TYPE I', </font></blockquote><br>
But, of course, that is really the point. The client _did_ reverse
the mode, which had been set by user request using a plain old BINARY
command. So it is really more surprising that it doesn't undo what
it just did, so as to put things back the way the user wanted them.
<br><br>
It is true that another sequence of commands to try would be<br>
binary<br>
dir<br>
get foo<br>
and see whether/that the client program does a "TYPE I" at that
point.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>for example running
SIZE, but, since you did that with QUOTE, the<br>
client had no way of knowing that you need the mode
reversed.</font></blockquote><br>
And the user had no way of knowing the client was diddling the mode
behind the scenes ... :-)<br><br>
<blockquote type=cite class=cite cite=""><font size=3>-- <br>
Dariush Pietrzak,</font></blockquote></body>
</html>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ProFTPD Users List <proftpd-users@proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic