--------------------------------------------------
From: "Jonathon Veencamp" <[email protected]>
Sent: 09 February, 2010 20:03
To: <[email protected]>
Subject: Re: [us...@httpd] How to force CRLF on non .txt files when directory
browsing?
I'll quantify the problem a little better. If I go on linux to the
directory I am browsing via the HTTP server and issue these commands:
# touch test.log
# echo one >> test.log
# echo two >> test.log
# cp test.log test.log.txt
If I use my brower to open test.log, it launches notepad on Windows which
contains a single line:
one two
and this has a square character after each of the words. Undisplayable
character. If I view this in a hex editor, it's just a LF.
If I use my browser to open test.log.txt, then the browser displays
one
two
And if I do a view source in the browser, then it is simple text with no
tags. If I view this in a hex editor, it has a CR/LF. So obviously the
HTTP server is processing it differently. What I want is for the server to
treat .log files the same as it does .txt files. But I'll be darned if I
can find anyone else that tried to solve this same problem. I've googled
for hours on this. Though maybe I'm a poor googler. ;-)
TIA
Jon
On Tue, Feb 9, 2010 at 1:51 PM, Jonathon Veencamp <[email protected]>wrote:
I don't think it's a poor editting thing. I think this is the difference
between Unix and Windows and CR/LF on Windows versus LF on Linux. The HTTP
server is adding CR/LF to .txt files to display them correctly in the
browser. But I can't get it to display .log files in the same manner.
Thanks both of you for the very quick replies. This is my first question
via this list, and it was suprisingly fast response!
Jon
On Tue, Feb 9, 2010 at 1:40 PM, Daniel Reinhardt <
[email protected]> wrote:
--------------------------------------------------
From: "Jonathon Veencamp" <[email protected]>
Sent: 09 February, 2010 19:31
To: <[email protected]>
Subject: [us...@httpd] How to force CRLF on non .txt files when directory
browsing?
Hello,
I've beat my head on this wall far too long, and googled the heck out of
it,
so I'll ask the mailing list on what should be a simple problem.
I have some text files on a linux host with .log and .properties
extensions. When these are sent to a windows browser, they do not have
CR/LF and so each line wraps to the next and they don't format well in
the
browser. I would like to have the Apache HTTP server treat these the
same
as .txt files, but I've been unable to find the configuration I need to
change.
I tried adding
AddType text/html .log
AddType text/html .properties
and that didn't do it. Then I tried
AddHandler type-map .log
AddHandler type-map .properties
and that was a no go.
I tried adding these to the mime.types file.
About all I can think of now is to process these files via a CGI script
to
output them line by line with a <BR> if necessary, but that seems like
complete overkill.
Can anyone help?
TIA
Jon
Jon,
I think what you are experiencing is poor editing or formatting of the log
files when they were saved, are these log files created and then placed in a
file? Or are they stored in the directory you currently have them?
Thanks,
Dan
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
" from the digest: [email protected]
For additional commands, e-mail: [email protected]
Jon,
Then move the log files to a txt document. It is asking you to open notepad,
because your browser doesn't know how to handle *.log extensions. Its something
to do with how the browser sees the octet stream and application type via
mime.types I think. I am no expert, but I am only speculating on why this
happens.
Thanks,
Daniel
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
" from the digest: [email protected]
For additional commands, e-mail: [email protected]
