Tom Jackson schrieb:
Hey,
I just noticed that my patch to queue.c misses one case. If an
authorization proc returns NS_ERROR, a 500 response is returned, but no
trace filters run. This seems like a bug, ...
i was as well looking at the result of Ns_AuthorizeRequest, and
not at the result of a filter proc.
> More filters and the traces are run, when the status is NS_OK
> or NS_FILTER_RETURN. If i look at the code, i wonder,
> what happens with filters and traces for status codes like
> NS_FORBIDDEN, NS_UNAUTHORIZED, or NS_SHUTDOWN?
>
Since the status code is handled in the same proc,
we have to deal with it consistently
To be consistent, the NS_ERROR/default block should be:
case NS_ERROR:
default:
Ns_ConnReturnInternalError(conn);
status = NS_OK;
break;
That is still just one case. If i read the code correctly even with
the patch above, the trace filters and the traces are not run
when AuthorizeRequest returns NS_FORBIDDEN or
NS_UNAUTHORIZED. Therefore, these entries won't
show up in the access log-file, which looks as a bug to me.
The return codes NS_OK and NS_FILTER_RETURN (which
can be set by a filter, by the request or the authorization)
mean in the 4.5 code-line:
NS_OK:
run filters with NS_FILTER_TRACE,
run filters with NS_FILTER_VOID_TRACE,
run traces
NS_FILTER_RETURN
run filters with NS_FILTER_TRACE,
which is something i don't understand.
By looking into the code, i see that a VOID_TRACE
filter is registered by the NsTclRegisterTraceObjCmd
(when a trace is registered). Why we have actually
TRACE and VOID_TRACE?
Wouldn't be a single TRACE enough?
Shouln't be servertraces marked as deprecated
in favor of TRACE filters? (or vice versa)?
nslog is the only place, in the common code,
where a servertrace is registered. This could
be replaced by a call to register a TRACE filter.
Then, we should simplify the distinction
between NS_OK and NS_FILTER_TRACE
to a single case, where the traces are always
run. That would be a nice simplificaton
and would make it easier to achieve a
consitent behavior.
-gustaf neumann
PS: i wrote this just by reading the code.
There might be certainly some imporant
cases/reasones missing.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.