The problem: I want to serve
CRLF from files encoded as
I have an apache2 httpd linux-based web-server configured to serve up (large) log files (
*.log) generated by a linux-based simulator.
These log files have the Unix-style
LF ending rather than Windows-style
CRLF also turns out to be the standard for text files in the
When I view them using a browser in Windows they are loaded into Notepad.exe and all the text is (incorrectly) on the same line; unless I rename the logs on the server from
It seems to be that Microsoft Windows is probably handling
*.txt specially, and converting the endings as they arrive.
Given these clues, how can I change the set-up so client users see the files correctly, regardless of their platform/browser.
More problem detail: why I can't do the obvious thing
Analysing the logs, I find that
.txt is served as mime-type
text/x-log, but switching
SetType didn't solve the problem.
In a production system, I will not easily be able to change the files to end in
The logs are too numerous and large for me to want to convert using (e.g.
unix2dos) and save another copy. Also that would force me to manage an additional cache of converted files that would need to be invalidated, cleared up etc, or to change the original files, which may break other systems that consume them.
- Is there an Apache httpd configuration parameter that tells Windows/Internet Explorer (and other OS/browser) that it needs to expand
CRLFas it arrives?
- OR Can I somehow tell Apache to replace
CRLFon the fly as it serves it up?
What I have tried
The Apache documentation is quiet on the line-ending issue.
The MIME documentation on the
text type says the content must be in CRLF format.
It also appears that line-ending is not considered by the charset encoding standards.