Justin Erenkrantz <[EMAIL PROTECTED]> writes: > --On Thursday, October 31, 2002 6:10 AM -0500 Jeff Trawick > <[EMAIL PROTECTED]> wrote: > > > incorrect doc (util_filter.h) which says that APR status codes > > should be returned > > I'm confused. Why is that incorrect? APR status codes *should* be > returned by the filters. If a filter has an error, it should be > producing an error bucket, passing it down the chain, and then > returning an APR error code (well, Ryan always said it should pass > APR_SUCCESS back, but I never quite agreed with that). > > About the only filters that can't punt like that are the connection > filters. They should be returning an APR error code in this > case. Then, the http_output_filter (?) could detect the connection was > aborted and set r->status to whatever it likes. > > To me, it sounds like when c->aborted is set, APR_SUCCESS is returned. > That's the problem, isn't it?
First, I suspect that you and I widely agree on how it should work. Most of your response is simply preaching to the choir :) I believe that you and I probably interpret how it is "working" now differently though. This is an overall design issue which needs to be resolved. That one line (what to return when the connection is reset) is not the entire problem. We're at the point where Ryan's desired design isn't completely implemented and how you think it works isn't completely implemented either. Both designs are off by more than a couple lines of code. Thus my message. default_handler(), which should be returning HTTP status code, returns whatever ap_pass_brigade() returns. default_handler() would have to change too. Any other handlers as well (In the thread I pointed to, Ryan claimed that 99% of handlers return whatever ap_pass_brigade() returned. So I suspect that some other handlers need to be changed as well.) > > a filter can return non-200 after the status line has been > > written to the network... what is the meaning of that w.r.t. > > logging? > > How is that possible? This point was a complaint against the design which Ryan espoused and which is partially implemented, not against how you or I would like it to work. An error can occur after the status line has been written (e.g., db lookup fails or something when filtering... make something up :) )... If the retcode of filters is logged (which it is), then the filter has to report the failure in a way that causes a valid HTTP status code to be logged. But like I say, what is the point of returning non-200. Code playing with HTTP status codes should be analyzed to ensure that what is logged is what was written to the client (I guess?) (i.e., some subsequent error doesn't overwrite r->status or whatever is passed to the logger). clear as mud? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
