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

[ME]

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.

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.

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

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

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

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

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

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

-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