On Tue, May 28, 2002 at 03:13:50PM -0700, Ryan Bloom wrote:
> You should set r->status to 400 (BAD_REQUEST) and return an error
> condition, most likely the HTTP status code, although ap_getline will
> throw away the returned value in favor of r->status.
Actually, ap_http_header_filter sets r->status for us, so that's
not a problem.
The problem I'm currently having is that the subreqs generated
by the error page (HTTP_REQUEST_ENTITY_TOO_LARGE.html.var) is
calling ap_discard_request_body() - which gets us our loop back
into HTTP_IN (ap_http_filter).
I'm adding code to the beginning of ap_discard_request_body like the
following:
/* Sometimes we'll get in a state where the input handling has
* detected an error where we want to drop the connection, so if
* that's the case, don't read the data as that is what we're trying
* to avoid.
*/
if (ap_status_drops_connection(r->status) ||
(r->main && ap_status_drops_connection(r->main->status))) {
return OK;
}
The idea is that if our status code is such that we're trying to
avoid reading the body, we shouldn't actually read it. We need
the r->main trick as well because of subreqs (the .html.var file
is a subreq handled by default_handler, so it will call discard_body
as well on each subreq!).
How does this sound? -- justin