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).incorrect doc (util_filter.h) which says that APR status codes should be returned
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?
Again, why not return something other than APR_SUCCESS when c->aborted is set?several troubling aspects of the interface:every filter that does further processing after ap_pass_brigade() (e.g., content-length filter) should check retcode and c->aborted after ap_pass_brigade() to see if it should continue processing
Correct, but filters don't understand HTTP and never will. If you restrict ourselves to HTTP-only, then how do we deal with other protocols? In fact, there should only be one filter which has knowledge of HTTP - the http_output_filter. Nothing else should be aware of what protocol we're using.retcode type apr_status_t isn't the perfect match for HTTP status code... the HTTP status code could be stored in a user code range within apr_status_t but that isn't done now
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?
IMHO, real APR status codes *are* the natural thing to return
from a filter... it isn't like bucket read returns an HTTP code
:) it isn't like our portability layer maps local errors to
HTTP codes either
Right, so I'm confused as to why you are trying to change it here.
"bad" filters (return real APR status codes when the going gets tough):
No, I say they are the 'good' filters. =)
"good" filters (return real HTTP codes when the going gets tough)
I say these are 'broken' filters.
while core_output will rightfully set c->aborted if it encounters a dropped connection, and thus doesn't have to make up a bogus status code, how many other filters have that option?
Have it return APR_ECONNABORTED. I'm really confused as to what your complaint is. -- justin
