W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Q?: Tx of text type docs and CR/LF, CR, LF translation

From: ME <dugan@passwall.com>
Date: Wed, 3 Jul 2002 12:17:13 -0700 (PDT)
To: w3c-dist-auth@w3.org
Message-ID: <Pine.LNX.4.21.0207031151160.25552-100000@nerds.passwall.com>


I have searched with google, read afew dav FAQs, and looked through some
RFC before posting this message here. This is my first post to any W3/IETF
list, so please bear with me for any mistakes I may make. :-)

Problem: When WebDAV enabled clients (tested with "MS Web Folders",
"Cadaver", and "Goliath") request a text file (text/plain, text/html) from
a DavEnabled Webserver (in this case Apache 1.3.26 with mod-dav-1.0.3
running over SSL) the file is transmitted from the server with the same
line termination the file had when examined on the server from a shell.

Files previously edited with SimpleText (MacOS), or notepad (Windows) and
stored on the server with netatalk-asun or samba contain CR (^M) or CRLF
(^M^J) respectively. Files created from Linux bash with emacs/vi have the
LF (^J) as the line termination char.

Files created strictly from a Mac are not in "human readable format" when
the windows user opens then with notepad.

Files created strictly from a Windows box are not in "human readable
format" when the mac user opens then with SimpleText.

Forcing users to use a web authoring tool, or "BBEdit" (Mac) or something
like Codewarrior Editor (Windows) that can deal with the 3 common line
terminations strings for files and leave the file in "human readable
format" are known, but not desired.

Web browsers (Netscape, MSIE, Lynx) read these files from the same web
server and perform proper translation such that the browser
subsitutes the client OS's own line break for the served content's body
(or file's contents.)

This seems to echo rfc2616 , section: 3.7.1 
    "Canonicalization and Text Defaults:"
( http://asg.web.cmu.edu/rfc/rfc2616.html )

"When in canonical form, media subtypes of the "text" type use CRLF as the
text line break. HTTP relaxes this requirement and allows the transport of
text media with plain CR or LF alone representing a line break when it is
done consistently for an entire entity-body. HTTP applications MUST accept
CRLF, bare CR, and bare LF as being representative of a line break in text
media received via HTTP."

So, here is my thought:

If RFC for HTTP/1.1 states "HTTP applications must accept CRLF, bare CR,
and bare LF as being representative of a line break in text media received
via HTTP." and WebDAV clients are considered HTTP Applications, and the
specs for WebDAV include use of HTTP for transmission of text type docs,
then shouldn't WebDAV clients also "inheirit" this requirement from

If so, could this be included to be more explicit in the present RFC for

Presently, I am using mod_rewrite and server side processing with
directory forward inheiritance to process through DAV based requests for
files and perform translation to the end of line termination string of the
DAV requests files based on the client string submitted in the request.
This is clunky and is not the "right solution" and I am looking for
somehting better such as getting vendors of WebDAV based clients to


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
Received on Wednesday, 3 July 2002 15:20:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC