- From: Lisa Dusseault <ldusseault@xythos.com>
- Date: Wed, 3 Jul 2002 16:18:49 -0400
- To: "ME" <dugan@passwall.com>, <w3c-dist-auth@w3.org>
The problem you describe is not particularly a WebDAV problem. IMAP and FTP are subject to the same problems. MIME also does not attempt to fix the problem. The HTTP 1.1 specification does make some attempt to improve the situation, and it works *when viewing in the browser*. It's not clear how browsers should save files though. The browser could: - save the file the same way it was downloaded - save the transformed file, replacing single CR or LF with CRLF Either approach leads to problems. The current common approach, where the browser saves the file the way it was downloaded, means the file may be unusable when viewed in various text editors. However, if the browser transforms the file, it may be altering the file inappropriately. The transformation assumes that wherever CR or LF is used CRLF is appropriate, and that may not be true for all uses of 'text/plain'. I see why you wish attention to be brought to this subject, but the real offenders are not WebDAV clients. It's applications like NotePad that can't display reasonable file formats that are problematic. Those implementers are unlikely to read this list or the WebDAV specification. You might try reporting this behavior as a bug to the manufacturers of the offending software. Lisa -----Original Message----- From: ME [mailto:dugan@passwall.com] Sent: Wednesday, July 03, 2002 12:17 PM To: w3c-dist-auth@w3.org Subject: Q?: Tx of text type docs and CR/LF, CR, LF translation Hello, 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 HTTP/1.1 RFC? If so, could this be included to be more explicit in the present RFC for WebDAV? 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 change. Thanks! -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
Received on Wednesday, 3 July 2002 16:19:52 UTC