[vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LF issues w/ MacOS+MSWin

[Micah Cowan]

Jeff Newmiller writes:
 > On Wed, 3 Jul 2002, ME wrote:
 > 
 > > Attempts to copy *.txt files created on the server (from scratch in emacs,
 > > or vi or jov) lead to files when copied through WebDAV "MS Internet
 > > Folders" to the windows desktop lead to files (when opened with
 > > notepad) that have small "block" chars representing the linux ^J and no
 > > line breaks for the content shown in notepad.
 > 
 > Server issue... server should have produced CRLFs on output.

<snip>

 > > > > If the 3 of the 4 can be changed, I expect the 4th can be changed. If 4 of
 > > > > these 4 are changed, then it can become a defacto standard, and may get
 > > > > added to the RFC as a "should" or "may" even if it is not a "must".
 > > > 
 > > > Now it is my turn to be confused. What are you enumerating?
 > > 
 > > I was looking at inertia in code development. If you can get 75% of the
 > > market to swtch, you have more leverage to convince the last 25% to
 > > switch. (1)cadaver, (2)Goliath, (3)iDisk, (4)MS Web Folders. Getting two
 > > to switch should be possible. If either Apple or MS switch it might be
 > > easier to convince the last to switch.
 > 
 > Yes, 1 through 3 have to change.  4 does not.

<snip>

 > Read Step 2 "Conversion to canonical form" in http://RFC.net/rfc2049.html.
 > This is as close to "MUST" as I have found so far.

HTTP (RFC 2616) specifically excludes "text/*" media types from having
to be in canonical form, in sect. 3.7.1. Therefore, your arguments are
unfortunately incorrect; a server is 100% within its rights to send
CRLF, CR or LF- terminated output (in the entity-body, that is -
naturally, headers and such are CRLF terminated). Every server I've
ever come across (including Apache, which I have a great deal of
respect for) sends text media exactly as it finds it, which is
perfectly acceptable. It is required of the client to correctly
interpret any of the above as line terminators (which is why pretty
much every browser will display a text URL correctly, regardless of
the EOL terminator - it's required to).  However, the clients
described above (at least, the ones I know about) don't do any parsing
or display of text at all, and so aren't beholden to recognize *any*
EOLs (even though they're being incredibly stupid not to).

I'm shocked that so many DAV clients have this mindset.  And didn't
one of them cite FTP? FTP *does* support transliteration, of course,
so they don't seem to know what they're talking about - but how can
they expect their products to be useful if they don't accomadate the
OS? And it's such a trivial thing to do, too.

Micah