Andrew, If the connection has been closed, nothing will be sent. But anyone who uses streaming output will have to live with the possibility that an error will occur mid-response. I don't recommend using streaming output for many reasons, but the most obvious is the one you mention: you (the generic developer) made a mistake in assuming that the response would complete without error.
HTTP supports chunked output to handle situations where an entire response could never fit into memory. Anyway, there are many useless rules in the HTTP standards, but the basic signaling of what happened and maybe why is not in this category. Beyond returning information to the client, it is also useful to log the correct response code. My second to last post included a long list of observations about AOLserver code. One of these observations is that the AOLserver API includes a number of API which seem easy to use but actually require a lot of care in application. The entire ADP API falls into this category and also extends to ADP configuration options. What that means is that even with bug free API code, application developers must do lots of experimentation to verify how stuff actually works. The patch is not an attempt to change the basic algorithm of request processing. There were a few bugs which allowed confusion of actual errors and adp signaling. And there was the original behavior of skipping trace filters, including logging, when an error occurred, and this behavior has changed over time. My patch fixes a few bugs and applies the same error handling to all errors, regardless of where they occur. One other note: the ns_adp_ctl seems to have some bugs. Errors are only logged once (after calling ns_adp_ctl stricterror 1), and then the error logging flag seems to remain in place forever. It seems that this flag should be reset for each request, otherwise errors are not logged. tom jackson On Sat, 2009-04-04 at 16:25 -0500, Andrew Steets wrote: > Hi Tom, > > Attachments seem to work ok on this list. > > I don't think we can return 500 internal server error after > Ns_ConnRunRequest has been invoked as it may have already sent an http > response code via streaming output or ns_returnxxx. > > -Andrew > > On Sat, Apr 4, 2009 at 12:00 PM, Tom Jackson <t...@rmadilo.com> wrote: > > Here is a test patch for the ns_adp_abort issue. > > > > The patch enables sending an error message in the case of an actual > > error during adp processing, or after a postauth filter (preauth errors > > already allow this behavior). > > > > Also, logging is enabled in all cases. If an error occurs, a 500 > > response is sent and this is what is logged. > > > > I haven't tested this with ns_adp_break. But it works with ns_adp_return > > and ns_adp_abort as well as error handling in and adp. > > > > tom jackson > > > > Not sure if I can attach the patch, but here goes: > > > > > > > > > > -- > > 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.
