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.

Reply via email to