mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Gustavsson <nik...@protocol7.com>
Subject Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.
Date Thu, 28 May 2009 06:51:31 GMT
Sorry, my bad, I mixed up \r and \n. Let me rephrase:

1. If we get sent a \n only, should we print EOL or \n? Since \n is
not the canonical line ending in the RFC, we might not want to treat
this as a line ending that we should convert into the local line
2. if we get sent a \r\n, we should clearly print EOL
3. If we get sent a \r only, we currently print EOL. Given the
argument above, is this correct?


On Thu, May 28, 2009 at 12:13 AM, David Latorre <dvlato@gmail.com> wrote:
> 2009/5/27 Niklas Gustavsson <niklas@protocol7.com>:
>> On Wed, May 27, 2009 at 3:07 PM, David Latorre <dvlato@gmail.com> wrote:
>>> I added a fix and some tests but ToNetASCIIOutputStream in
>>> commons-util will always replace to \r\n so I'm uploading a modified
>>> version. With this fix ascii mode should not eat line separators
>>> anymore.
>> Thanks! Looking into the fix I'm not sure we should print EOL on \r.
>> Since \r is not the canonical line ending in the RFC, I think we
>> should rather print \r as it is in the stream. What do you think?
> I don't really know if \r has other users than being part of the New
> Line sequence. I guess \r could take us back to the beginning of the
> line ... but it doesn't make much sense in a file.
> My reasons to leave \r as the character substituted by EOL are 1)
> Because it was previously written in that way.   2) Mac OS 9 and
> before had \r as the new line separator, so if the line endings of a
> Mac OS 9 text file weren't transformed to \r\n and we were  ignoring
> \r , we would swallow the new line again. On the other hand, if we
> write the \r  character,  we cannot transform to Unix line endings
> which have no \r...
> So, I'm sure there are other options and they might be more
> performant, but this solution seems to work in several situations
> which are usually not supported and the code is fairly easy to
> understand ...
> Of course, for me , the best solution is to entirely remove the ASCII
> mode  from the RFC :-D
>> /niklas

View raw message