2009/5/28 Niklas Gustavsson <nik...@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 <dvl...@gmail.com> wrote: >> 2009/5/27 Niklas Gustavsson <nik...@protocol7.com>: >>> On Wed, May 27, 2009 at 3:07 PM, David Latorre <dvl...@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 >>> >> >
