Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http logging doesn't seem complete, even w/ -l debug #25

Open
mindsong opened this issue Mar 23, 2021 · 3 comments
Open

http logging doesn't seem complete, even w/ -l debug #25

mindsong opened this issue Mar 23, 2021 · 3 comments

Comments

@mindsong
Copy link

mindsong commented Mar 23, 2021

Hi there!

Building from the current master (as of this note's timestamp)
Linux xxx.net 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux

The build worked fine, new package was created and installed.

merecat -V
2.32-rc4

Seems to operate well enough from a browser's view with a minimal port-80 initial test install, except for the traffic logging only seems to show errors like 304 and 404 best I can tell, even when started with

merecat -n -f /etc/merecat.conf -l debug

(all messages to stdout, right?)

with /etc/merecat.conf containing only:

username = www-data
directory = /var/www

Your default merecat webpage content is in /var/www and displays correctly, but the only logging I can see is the process start-up info, the http 404s and the 304s - no 200s.

Further (another bug report?) the man page indicates CLI -r and -d options, neither of which works or appears in the merecat -h usage message, as well as some of the other merecat(8) listed options (still on the todo list?)

Lastly, why is it that the newly built deb package that builds from my updated/cloned repo indicates install files with modify dates of "July 7, 2020" on all of the installed files? The 'dpkg-deb --contents' of the new deb file shows the same. Odd that, even after a "make distclean", ./autoconf.sh, ./configure, make package sequence, the resulting installed files in /usr/sbin/merecat are dated July 7, 2020. Is there a forced date in the package build rules (I'm not too savvy about pkg building)?

But thanks for keeping this little gem alive (I've been using thttpd for years now, but it's time for me to upgrade..., and your updates tie it all up very nicely - ssl, etc.)

I hope this info helps, and I can test further if it will help.

cheers,
mindsong

@mindsong mindsong changed the title mindsong http logging doesn't seem complete, even w/ -l debug Mar 23, 2021
@troglobit
Copy link
Owner

It has been many years since I started patching up this fork, so I don't remember all the design decisions I made, but this project is not thttpd, so you cannot infer any behavior it had on this project. Also, the master branch is unreleased and still very much under development. The issues you mention about .deb package and out-of-sync command line options are not something I'll go into detail on, but I'd say normal state for an in-progress project. There's a lot of bigger issues to address before turning to fix them. Meanwhile, there are released versions (with lot less features) that I recommend to anyone who want to use this project for now.

@mindsong
Copy link
Author

mindsong commented Apr 4, 2021

Hello Joachim (troglobit),

Thanks for the reply, and thanks for keeping this handy tool alive.

I appreciate that your make-over of the original thttp project is ongoing and quite substantial, if not almost a rewrite. I'm also very pleased that you have preserved the original "way of thinking" that Mr. Poskanzer designed into the original tool. Bravo for that.

I was hoping that the logging problem was a 'user error', or perhaps it was a runtime or compile-time setting that hasn't been fully detailed in the documentation yet. I can look into the repo and perhaps see if I've missed something. I expect that the logging code is present and mature, simply not enabled due to the way I am running the program.

I'm not at all worried that the deb package mechanism hasn't been updated. It only caught my eye when the file date in /usr/sbin was 2 years old and I had just built and installed it - that was unexpected, and made me wonder if I was doing what I believed I was doing. I'm glad to know that it's not unexpected at this point.

I have a great understanding of 'works in progress' that don't claim to be complete (current/master branches), but are treated as though they are complete anyway - look at the piles of projects on my desk for verification of that! :). My feedback is intended to help identify user-problems, or program issues before they become releases!

As mentioned before, thanks for your continued work this wonderful little tool. Perhaps I could help with some of the more peripheral updates to the codebase - e.g. documentation and examples of usage if that would be helpful. I will peruse the repo before I make promises that may be over my head!

best, and thanks for the reply,
--ms

@stappersg
Copy link
Contributor

I also miss 200 OK in logging, same as in original report of this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants