On Wed, 12 Jul 2006, Yutaka Sato wrote:
> It is possible that konqueror is sensitive of the physical packet
> sequence of FTP responses on TCP.
> To suppress the inclusion of remote server's message into the response
> to the client, you can specify as
It's working now!
Because of this, I'm wondering whether I should file a bugreport for
konqueror. I checked RFC959, section 4.2 says much, something I cannot
decide whether it is written there as brain storming or so, but the
example is quite good:
Thus the format for multi-line replies is that the first line
will begin with the exact required reply code, followed
immediately by a Hyphen, "-" (also known as Minus), followed by
text. The last line will begin with the same code, followed
immediately by Space <SP>, optionally some text, and the Telnet
234 A line beginning with numbers
123 The last line
The user-process then simply needs to search for the second
occurrence of the same reply code, followed by <SP> (Space), at
the beginning of a line, and ignore all intermediary lines. If
an intermediary line begins with a 3-digit number, the Server
must pad the front to avoid confusion.
This scheme allows standard system routines to be used for
reply information (such as for the STAT reply), with
"artificial" first and last lines tacked on. In rare cases
where these routines are able to generate three digits and a
Space at the beginning of any line, the beginning of each
text line should be offset by some neutral text, like Space.
I see that the reply of Delegate does not "try to avoid confusion" as the
commentary paragraphe calls it, by doing that Delegate uses different
replay codes in front of the inner lines and does not quote them.
There is the possibility that konqueror ignores the multiline response,
when the reply code is the same on all the lines, because even with
hideserv the initial response is multi-line with a three-digit<hyphen>
prefix, but all the codes are the same. konqueror passes this comment.