> What would be even better is to just write the code right in the first place > so that no error ever happens. (I tried that. I came close.)
People make mistakes. Server software should do something reasonable. The problem with just closing the connection is: - the user will get "connection has been reset by peer", which could be caused by several things - there will be nothing logged in the server log files, like 500 errors that would show up in log analysis, i.e., the people running the server don't even know something bad is happening Especially with complex code that may be dependent on a number of things, all code paths don't always get tested. Sure, it's bad - but it's a fact of life IMO. > Yes. I am arguing that the server should always return a 500 if it reaches > the end of a connection with no other results. I don't know the technical > feasibility of this but it does not seem like correct behavior to return > nothing to the user. Totally agree. In fact, I think there may be other cases where AS 3.4 doesn't log Bad Request errors that are internally generated by AS. I have had users do screen shots of Bad Request, yet I can't find them in my logs. Could be stupidity on my part...dunno yet. Jim > > I'm confused by the "O/ACS is replacing the http protocol with the filter" > reference. The O/ACS is just using the documented ns_register_filter command > for it's intended purpose. > > On Sunday 06 January 2002 10:52 pm, you wrote: > > David Walker wrote: > > > When the error below appears wouldn't the proper response be a 500 server > > > error? The 3.4 way of handling this is to return nothing. > > > > > > Error: tclop: invalid return code from filter proc 'Critical filter > > > sec_read_security_info failed.': must be filter_ok, filter_return, or > > > filter_break > > > > This is an uncaught error in a filter. Since the O/ACS is replacing the > > http protocol with the filter, you could argue that it should return > > 500. What would be better would be for the application to log an error > > that would let the developer determine if it was a bug or some other > > error. For instance url hacking could also give this error, or many > > other database errors as well. > > > > --Tom Jackson >
