Should WebDAV servers use text mode to open and store text files?

Question

I am wondering if a WebDAV server should store uploaded files in text-mode, if the mime-type is 'text/...'.

Unix, Windows and Mac OS use different line endings. Opening a file in write+text mode may convert carriage return / newline according to the servers system convention (which may be different from the WebDAV client).

The obvious alternative would be to store all incoming files as binary blobs, without any conversion.

I see this pros for text-mode:

• The text files can be opened on the server using text editors
• The uploaded text files may also be easier to interpret by server software (i.e. xml parsers, script processors)
• All clients get all text files with the same line ending convention (as defined by the server platform)
• I think I have seen implementations doing this

and this cons of text mode

• A client cannot expect to GET the same file content that was POSTed.
• If a Windows WebDAV client stores a file to a Unix server, the file sizes are different. I. e. the resources 'size' property is greater than the length of the data returned on GET.
• Dangerous: if a file claims mime type 'text/foo', but the file is in fact binary (e.g. a zipped xml file), converting \n \r bytes will corrupt the file.
• Text mode may be slower, since processing is required(?)

Am I missing something? How do common WebDAV servers handle this? Is there a best practice?

Answer 1

I don't know how common WebDAV servers handle this, but I think it's a bad idea.

Just the risk of damaging binary files that are thought to be text, as you mentioned, makes it not worth doing. Here are some more disadvantages:

• Breaks the model of the WebDAV server as a simple storage and retrieval device. As a user:
  • I'd view this as mangling my files.
  • I'd have to spend time figuring out how and why my files had changed.
  • Then I'd wonder what other things the server might be doing to my files on my behalf.
• Changes line endings based on the server's OS, not the client's (customer's).

If I'm a Windows-only or Unix-only user, then all my line endings are right for me, and I don't want the server changing them. If I use both, then I already have tools that are either insensitive to the line endings or can convert between them.

My experience with text-processing client programs in recent years is that they're all insensitive to line endings. XML parsers and script interpreters, for example, can work with either style of line ending. So I don't see much benefit to offset the risk.