Jeff Trawick <[EMAIL PROTECTED]> writes:
> Maybe I can find time to review any old discussion about this to see
> if there were good reasons for changing the output filter interface :)
See the discussion back in March 2002 with subject
[PATCH] invalid HTTP status codes in access log
I don't see any consensus on how that problem should have been fixed
(which is perhaps a lame way of saying I don't like what was
committed). Something was commited and some important questions led
in other directions. Hopefully this can be resolved in 2.1 timeframe.
What we have now is:
incorrect doc (util_filter.h) which says that APR status codes
should be returned
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
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?
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
"bad" filters (return real APR status codes when the going gets tough):
content-length
deflate
include
mod_ext_filter
mod_charset_lite
"good" filters (return real HTTP codes when the going gets tough)
core-output
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?
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
