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

[ME]

On Thu, 4 Jul 2002, Micah Cowan wrote:
> 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).

Yeah, I included this part of the RFC in one of the earlier message in
this discussion here and in the WebDAV workgroup. I don't like it that the
WebDAV isn't be considered an HTTP application with local OS rewriting of
line breaks for saved text files. The item of arguement used by the
workgroup effectively stated that they see that rule only applying when
"displaying the content in the browser" and there is no "explicit policy
on how the files should be saved." (Not my ideas on ths subject.)

I have enough evidence gathered to show files are sent with their own
breaks over the wire to no longer feel any need to convince others of it.
(Used a sniffer for testing to verify and saved content from various web
browsers.) Perhaps web browsers other than Apache for Linux (like MS IIS)
do the CRLF on the wire for body content transmission when the original
text files do not have CRLF? I might expect something like that.

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

I agree that it should be in the clients.

Well, I now I have a proof of concept unweildly hack for the Apache web
server with mod_dav to allow the server to deal with text files that have
known text extentions. When they are puled from the server, the files are
modified on the fly to meet the line breaks of the OS associated with the
DAV client. When the DAV client pushes a file with same known text
extentions to the server, the file is also modified to be stored in the
server's line-break format. (Bi-directional linebreak conversion.) This of
course does mean that the text file's content is at risk for change but
only with linebreak chars (CR,LF).

In addition to parsing being set to use only explicitly included extention
names, it also only works on clients by their offered name - so if the
clients ever get "fixed", the routine for this can be removed/changed and
left to the client to deal with appropriately.

I have verified the files are changed as I wish, but there is one error
box I need to eliminate that pops up when you store the files over DAV to
the server. After it works for my users, I'll see what I can do about
changing some clients out there and then throw up a web page to show how
it was done.  ]:>

-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