This thread has turned into an interesting discussion of what may be a
fairly useful ADP programming idiom, but I don't want to focus too
much on ns_adp_abort. There are other cases that will cause the ADP
to run without generating an access log entry. For example, if you
call one of the ns_returnxxx family of functions within an ADP, no
access log entry will be created regardless of whether or not
ns_adp_abort was called. I think there are more cases but I can't
come up with any right now.
I suspect, though I have not had time to confirm, that in aolserver
4.0 this was not a problem. If anyone has a testing 4.0 instance can
you please run a quick test?
If we decouple the web developers from the people who monitor and
administer the web server I think it becomes more clear. If I am a
security administrator, I want to know all the URLs that have been
accessed on the server, regardless of what the ADP code does. If I am
a systems administrator, I want to know how much data was sent out in
response to any request, and how much time it took to process the
request (I'm a *huge* fan of logreqtime), regardless of what the ADP
did.
The patch I sent earlier seems to fulfill these needs, but I am
worried about corner cases where LogTrace (from the nslog module)
could blow up. Nothing about the state of the Conn * seems to be
guaranteed when the ConnCleanup callbacks are called.
-Andrew
On Thu, Mar 26, 2009 at 6:34 PM, Tom Jackson <t...@rmadilo.com> wrote:
> By a strange coincidence I needed had a similar issue with Tcl (tcl
> pages).
>
> I did a ns_returnredirect way deep into an application. I was hoping to
> abort further execution of Tcl code, but by design, script execution
> continues.
>
> I considered that only throwing an error would unwind everything
> correctly. Since I hate the idea of doing this inside Tcl code, I
> decided to live with the problem.
>
> Then I discovered ns_tcl_abort. Here's the def:
> (from modules/file.tcl):
> #
> # ns_tcl_abort is a work-alike ns_adp_abort.
> #
> proc ns_tcl_abort {} {
> error ns_tcl_abort "" NS_TCL_ABORT
> }
>
> So if this is a work-alike, the intent could be to stop processing deep
> within some code, but it shouldn't have any effect on the logging.
>
> Note that ns_sourceproc catches the above error:
> proc ns_sourceproc {..} {
> ...
> if {$code == 1 && $errorCode == "NS_TCL_ABORT"} {
> return
> }
> ....
> }
>
> So I think normal logging should take place.
>
> The best evidence for normal logging is that ns_adp_abort is called
> intentionally, so the programmer can decide when to do it.
>
> tom jackson
>
> On Thu, 2009-03-26 at 16:11 -0400, Scott Goodwin wrote:
>> All connections should be logged as requests that came from clients
>> along with details on how the server responds. Some indication that
>> the connection was aborted should be made in the log, perhaps with a
>> count of how many bytes were transferred. In cases where no response
>> is going to be sent and the connection aborted, the response code
>> shown in the log could be left blank or as a placeholder (e.g. "xxx").
>> The general principle is that we always want visibility into what
>> happens with every connection -- in many situations we are serving
>> anonymous clients who aren't going to call and complain or post a
>> trouble ticket, so it's nice to see such aborted conns in the logs as
>> an indication that we might need to investigate what's going on.
>>
>> /s.
>>
>> On Mar 26, 2009, at 2:40 PM, Dossy Shiobara wrote:
>>
>> > On 3/26/09 1:31 PM, Andrew Steets wrote:
>> >> Hello,
>> >>
>> >> There are certain cases where connections probably ought to generate
>> >> access log entries but do not. Specifically if an ADP exits via
>> >> ns_adp_abort no access log entry will be generated, but data may have
>> >> been returned to the client. This seems like a bug.
>> >
>> > I wonder - should this be the documented known behavior of
>> > ns_adp_abort vs. ns_adp_return? i.e., abort indicates that the
>> > connection is intentionally terminated, not logged, etc. vs.
>> > ns_adp_return which halts ADP processing but continues the
>> > connection, which includes logging, etc.
>> >
>> > I'm inclined to agree with you that the current behavior is a bug,
>> > but it raises the question: should there be such a function that
>> > says "this connection wasn't handled, don't even log it" - or,
>> > should ALL connections always be logged, even if it's aborted?
>> >
>> > Thanks, Andrew.
>> >
>> > --
>> > Dossy Shiobara | do...@panoptic.com | http://dossy.org/
>> > Panoptic Computer Network | http://panoptic.com/
>> > "He realized the fastest way to change is to laugh at your own
>> > folly -- then you can let go and quickly move on." (p. 70)
>> >
--
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.
