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

[Micah Cowan]

ME writes:
 > 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.)

They're absolutely right, too - but that's no excuse. The goal of any
piece of software is hopefully to be somewhat useful, and by not
saving text files in an appropriate format, they're not being that.

To me, it's analagous to mail clients - according to RFC822 or
RFC2822, messages must be sent in canonical form; however, in
practice, most mail clients are very forgiving toward other
formats. Regardless of whether they accept them in canonical form,
however, have you *ever* seen a mail client for UNIX that fails to
save text/* messages in LF format? Not me. Same for the Mac and CR
format. Because they'd be stupid to save them in any other
format. Same for WebDAV clients - but apparently they haven't figured
that out yet.

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

That reverse conversion shouldn't be necessary. But I don't count
linebreak transliterations as content modifications, especially since
they're probably allowed.

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

You shouldn't use extensions at all - you should be basing it on the
MIME type, no? (for receiving, that is - not sending, where the MIME
type will be based on the extension anyway).

-Micah