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.