-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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. |
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, |
I also miss |
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
The text was updated successfully, but these errors were encountered: