Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Tue, 28 May 2002 15:19:27 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0 STATUS
Message-ID: <20020528151927.E2935@apache.org>
Mail-Followup-To: Justin Erenkrantz <jerenkrantz@apache.org>,
	dev@httpd.apache.org
References: <20020528143718.D2935@apache.org>
 <00ad01c20694$f237b9e0$8800000a@KOJ>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00ad01c20694$f237b9e0$8800000a@KOJ>;
 from rbb@covalent.net on Tue, May 28, 2002 at 03:13:50PM -0700

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