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

[Jeff Newmiller]

On Wed, 3 Jul 2002, ME wrote:

> On Wed, 3 Jul 2002, Jeff Newmiller wrote:
> > On Wed, 3 Jul 2002, ME wrote:
> [chop]
> > > > > 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. :-)
> > > 
> > > One memebers response seconded by another:
> > > 
> > > "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."
> > > 
> > > (Problem being the conversion of CR/LF, LF, CR to the local OS linebreak
> > > string.)
> > 
> > In one sense, they are right. WebDAV works through HTTP which is supposed
> > to define a solution to this problem.  In another sense, if WebDAV is
> > right there in Apache handling the response on its own and it screws it
> > up, then it is very much a WebDAV problem.
> > 
> > There is a standard for how text files are supposed to look on the
> > wire.  From there, every server and client should be able to convert to or
> > from their favorite format.
> 
> This was (mostly) what I wanted. Since the content on the server becomes
> exactly what is pushed from the WebDAV client, it should not be too much
> more work to do all of this conversion on the client end. If necessary, a
> rule could be imposed to have the clients convert the format back to the
> server format - but that is not required. So long as the client can
> convert from any consistent format to their native format, it does not
> matter what format is used on the server.

Except that most people expect text files on servers to behave like text
files, not binary files.  A CRLF file on a *nix server looks funky to
programs on the server.  Just because your current clients aren't doing
text processing there doesn't mean that someone, such as yourself, might
not want to do text processing there.

> Though i do like (from a support perspective) the idea of having this
> placed into the RFC for WebDAV clients, I can see other reasons for not
> including it.
> 
> It decouples OS specific limitations and restrictions from the protocol.
> It means less work for the maintainers of the RFC.
> It means less debate and arguement with the creators of the WebDAV
>    clients.

I can't tell what you are defending with these statements.  The last one
seems to imply that you are defending NOT including the standard text
format for on-the-wire transmission, but the other two imply that you are
defending the opposite (to me).

> > > And this brings me back to the original post where I stated "BBEdit" and
> > > the editor from MetroWerks Code Warrior can both handle file as text
> > > editor and properly display the content reguardless of the local OS's
> > > ideas on the matter with text files they create. I of course stated in the
> > > original post that these were undesireable.
> > > 
> > > So, unless I choose to look to help add a new feature to Goliath (checkbox
> > > to enable a text translation feature), Cadaver (a flag or arguement on
> > > startup) and beg MS to allow for client side alteration of files or
> > > Notepad, and/or ask Apple to alter SimpleText my two solutions include:
> > 
> > It is convenient that we don't have to change the behemoth's idea of
> > newline formats to be compatible with the standard on-the-wire format.
> 
> I am not clear here. Is the "Behemoth" Microsoft?

Yes.  The on-the-wire standard is CRLF, which MS uses on-disk.  This means
that MS programs can continue to send files in binary mode and be
compatible with the RFCs for text format.

> > > 1) Tell my users they can use "BBEdit" an editor like the one from
> > > CodeWarrior that understand the different conventions. (I know wordpad
> > > will deal with this for display, but when the file is saved, there is risk
> > > for contaimination of text data with 8 bit binary data and sequences to
> > > enable/disable bold etc.)
> > > 
> > > or
> > > 
> > > 2) Use the crazy-non-standard-web-server-hack that I made to automagically
> > > serve them a text file with line termination strings appropriate to their
> > > DAV Client's OS.
> > 
> > I don't think either solution is satisfactory.  I would setup the server
> > to push CRLFs for text files (being careful not to screw up unidentified
> > files) and push to get the clients fixed.  For inbound data, the hack
> > might be good if you have a useful ContentType header coming from the
> > client, but what a mess to maintain....
> 
> Oh no! The content modification hack is only for outbound files specific
> to users of webDAV clients based on extention - NOT for any other
> browsers. I could care less what the server content looks like. Of course,
> a bi-directional modification shifted to the clients would be good and
> would not find me complaining. :-)

That is exactly the trap I would prefer that you avoid... if you give in
and let all those different types of newlines be emitted from your server,
then you create an environment that will be incompatible when the authors
of the clients are convinced to start using a single text format on the
wire.  That is, your users are going to be pissed off at future client
updates because they "break" compatibility with your hack by doing things
the right way.

It would be good in general for text files to look like text files on your
server, so if you feel like putting in a hack to make that happen, I was
saying go for it.  You currently seem to think this is of no value, but
having different newlines in your text files on your server is going to be
a headache eventually.

> > > The same problem as before; should I push this problem to the clients, or
> > > accept the problem and own it?
> > 
> > There are thousands of potential applications that may produce or process
> > text. You do NOT want to try to push this on them.
> 
> Nah. I was only looking to the two above for the immediate issue. It is
> much easier to tell my users to use specific editors than to find all text
> editors out there. Though this is a possible option, I removed it from the
> list due to the work involved.

I am recommending that you make your server behave the right way, and tell
your users how to deal with the problem.  Then when the clients start
working correctly, your users may discover that "the authors of the client
programs fixed things to work right now" and they will then be able to use
whatever text editors they want to.

M$ users should need not training during any of this, for reasons
described above.

> > There are a limited number of WebDAV clients and servers.  Lobby them all
> > adhere to the established on-the-wire standard, and then every other
> > text processing application in the universe will magically be compatible
> > with DAV.
> 
> For the long term, this would be the best choice - I agree. I am sure I
> can contribute to Cadaver and Goliath, but am not sure sure I can convince
> Micro$oft and Apple to change their OS based WebDAV clients ("MS Web
> Folders" and Apple's "iDisk" system.) Granted, getting them to change
> these will still likely be easier than getting them to change SimpleText
> and Notepad - go figure.

M$ is home free.

Apple may have to fix their software, but it will be extremely easy for
them.

> Over the long term, i will agree this is a better track, but does not help
> me right now. :-(

Well, your Mac and Linux users will be inconvenienced, but you have
workarounds in hand.

> If the 3 of the 4 can be changed, I expect the 4th can be changed. If 4 of
> these 4 are changed, then it can become a defacto standard, and may get
> added to the RFC as a "should" or "may" even if it is not a "must".

Now it is my turn to be confused. What are you enumerating?

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------