On Thu, May 28, 2009 at 10:09 AM, David Latorre <dvl...@gmail.com> wrote: > 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.
I don't have an real opinion on this, merely asking the question. Maybe we should have a look at what other servers do. > By the way, do we support REST when using ASCII mode? I would say no, > but i'm not checking the code right now. Looks like we do, which could lead to file corruption right? /niklas
