mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Latorre <dvl...@gmail.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 08:09:40 GMT
2009/5/28 Niklas Gustavsson <niklas@protocol7.com>:
> 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
> ending.
> 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?
>
Oh sorry I didn't understand you before,  that's of course another
option - we only transform the canonical line ending and leave the
rest as is.  I don't know what are the advantages / caveats of those
options though.  Your proposal seems to be more strict to the standard
and thus, most preferrable. But in practice, this could mean that
sending the very same file from commons-ftp  will result in a
different file than if you sent it from filezilla (I don't know if
clients take the filezilla approach - just convert  the system's line
ending or they do as commons-ftp, convert all of them). But I guess
this is not an issue, they're  just line ending in the end ...

The discussion about the correctness of Filezilla in its
interpretation to the RFC  is not conclusive either. RFC says: " The
sender converts the data from an internal character  representation to
the standard 8-bit NVT-ASCII" ,  just "an internal representation",
not "the internal represention for its system" ...


So unless someone has a strong reason to need uniform EOLs
corresponding to the target system,  then we might assume that the
issue with different clients resulting in different files can be
ignored, and  transform only the canonical line ending.

By the way, do we support REST when using ASCII mode? I would say no,
but i'm not checking the code right now.




> /niklas
>
> 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
>>>
>>
>

Mime
View raw message