l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Jul 05 16:13

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


 > > > > 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.


 > 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.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.