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