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.
>
>
> --
> 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.
>
--
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.
