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

[ME]

> On Tue, 2 Jul 2002, ME wrote:
> > Web browsers seem to do this. However, when testing "MS Web Folders" and
> > "Cadaver" I have found they transmit the files with the actual
> > line termination encoding of the file.

On Tue, 2 Jul 2002, Jeff Newmiller wrote:
> So, if the on-the-wire format is supposed to be CRLF, which is native to
> Windows, and your server is not storing that as LF, then either the
> transmitted content type is wrong, or the server is not configured
> or programmed correctly.

Web browsers work just fine with text file (text/plain, text/html for
example) when served to standard web browsers. The browsers themselves
actually make the translation of the content.

WebDAV clients (Goliath, MS Windows Web Folders, cadaver (for Linux)) do
not appear to do any translation like the web clients (Nestscape, MSIE,
Lynx) have done and still do.

When a WebDAV client grabs a text file, the file is transmitted as stored
on the server. If the file was created with ^M termination only, then the
file received has ^M as line breaks. If the files tored on the server has
^M^J line termination, then then WebDAV clients (listed above) transmit a
file with those same breaks. The same file loaded with MSIE/Netscape
appears with transaltion as expected for the client OS's line termination
strings.

The RFC for HTTP/1.1 says the header is supposed to use CR/LF for HTTP,
but the body conversion to line breaks is left tot he client. With the
HTTP request, the "body" becomes the actual file (for the most part) but
not the header.

> This sounds vaguely like the reverse of the Netscape Communicator "MSWin
> bug". NS has a habit of believing the server's content-type, so
> downloading a binary file from a *nix web server that has not been told
> the file is binary will yield an on-the wire corrupted file.  A *nix
> Netscape client will fortuitously un-corrupt the file, but an MSWin or Mac
> NS Communicator yields corrupt downloads because it believes the file is
> text.  MSIE second-guesses the content-type, and usually downloads the
> file correctly.

http://asg.web.cmu.edu/rfc/rfc2616.html
...
"HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for tolerant
applications). The end-of-line marker within an entity-body is defined by
its associated media type, as described in section 3.7."
...
3.7.1:
...
"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."
...

(This, above, is what you mentioned in the previous e-mail as being a part
of http. WebDav runs over http.)

WebDAV clients are not doing this if "line break" is to be considered the
local OS's line termination string sequence when transmitting text files.

It later goes on to say that the CRLF sequence for header
information/options must use CRLF without substituition.

Ideally, the clients would need to perform the line break translations for
files of type "text" that are dowloaded from a Dav enabled web server.

Unfortunately, this does not happen in the Dav clients I have tested.

I have posted this as an issue to the "Microsoft news groups" complaining
about "MS Web Folders" not doing this translation. I have yet to post this
to the Cadaver or Goliath developers list, but will get around to it.

For now, a solution exists on my server to enable content modification to
server text files to DAV users and based on a matching search of their
client name/version, perform a translation of the text file
"on-the-fly" to use their native OS line termination char sequence. It is
not a "good solution" as all, but it does work to fill in this feature
missing in the clients.

It seems the "best solution" is to see if this can be added to Dav.

OK. Fine. I am subscribing to a ietf/w3 working group on WebDAV. If the
RFC for Dav can be modified to be explicit on content modification for
text files over http, perhaps the clients will add this feature. :-)

-ME


-----BEGIN GEEK CODE BLOCK-----
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?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html