Alvaro Lopez Ortega wrote:
Well, you know.. as everything else in the project, it is open to
discussion for enhancements :-)
In this case, I do agree, it would make pretty much sense to log an
error message if the CGI has the wrong permissions, but the problem
is that we can't know it in advance unless to add a new system call
to check it.
kind of. It's just a simple matter of recording standard error. after
looking in handler_cgi.c, execve is the vehicle you use for passing
control to the CGI program and if it returns you look at the error code
and either display a 404 or a 500 code. Haven't quite figured out how
you pass standard outback to the browser yet but that's the same place
to add the test to see if there's any data on standard error and write
it to the log.
another error that needs logging is:
192.168.0.30 - - [15/Mar/2006:15:17:08 --500] "GET /favicon.ico
HTTP/1.1" 404 0 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8) Gecko/20051111 Firefox/1.5"
1
Yep, you are right. Well, by the moment we have the undocumented
CHEROKEE_TRACE feature. However, it would be nice if we add a
better "information collector" because the tracing mechanism is
meant to be a debugging tool rather than a user utility.
It seems to be another new task for the upcoming unstable branch :-)
Ideas about it?
the very simplest form would be simply to have every request be at CGI,
file requests etc. etc. tell you what file or directory it's
referencing. A more useful system would tell you how it got there
(which part of the configuration, redirection etc.). I think it should
be a combination of a compile flag (i.e. -Dmake_me_slower) as well as a
configuration option to turn it on.
Directory /pic2 {
Debug
Handler redir {
Rewrite "/(.*)$" "/showpic.php?pic=$1&full=1"
}
}
would turn on all debugging for all handlers in the context of /pic2
So, if that behavior is configurable everybody would be happy.
sounds like a plan. I'm a big fan of assertions but I don't leave them
turned on once I'm confident of my code.
I used to like PHP (for what it is meant to be used, and no more!)
until I started working on the FastCGI handler. Dude, you can't even
imagine how much time I have wasted because of its brain death
FastCGI implementation! :-//
heat death of open-source universe is closer than it appears.
I have been seriously burned by a large number of packages over the past
year to the tune of a couple of hundred hours of labor I couldn't bill
for. The most recent was about 60 hours I spent on an Ajax interface
for camram to get around problems with slow training processes. I
couldn't get to work consistently, debugging was horrible, and the
documentation was piss poor. I eventually gave up and in about 20 hours
of effort, implemented a processing queue and user interface that tells
you how the messages are in the queue instead of showing you them in
process. Turns out to second interface is actually better because it
lets the user get done with what the need to do and move on but still,
60 hours really hurts to throw it away.
so yes, I can imagine quite well how much time you have lost on this
problem and I feel your pain. Just take care of your hands and arms so
you don't end up like me. (10+ yrs of RSI induced chronic pain and
counting).
---eric
_______________________________________________
Cherokee mailing list
[email protected]
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
