httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: ap_discard_request_body
Date Fri, 07 Jun 2002 06:52:11 GMT
On Thu, Jun 06, 2002 at 06:37:39PM -0700, Greg Stein wrote:
> > I don't think this case has to be considered an error.  We'll still
> > be compliant with 2616 if we return a 200 and discard a 100MB post
> > body that's been sent to, say, a static page.
> Right.

Here's the caveat:

Why do we want to return 413?  It is because we don't want to read
the body because it is too large, invalid, or requires too much
{network,CPU} bandwidth to do so.

We also can't "forget" the 100MB post body on a keepalive connection
because we'd have to read all 100MB in order to get to the next
request.  The only way this would be valid is if we were to ensure
that the Connection: close is set in r->headers_out, but if we could
do that, then we could just simply return the 413 in the first place.

So, I'm thinking we have to respect the limits and we have to
check this stuff before the handlers get to it.  This sounds
very similar to the 304 being bogus for php, include, etc.
We almost need something that lets the filters (input and output)
get initialized so they can check/set their pre-conditions.  At
least, this is what I'm contemplating.

> I think this is entirely up to the HTTP_IN filter. When a request
> terminates, that filter *knows* the body has not (yet) been read. It should
> just proceed to read it in and toss it.

Well, no.  HTTP_IN is never called at the end.  Or, if it is via
discard_request_body, it doesn't have a clue that the request is
terminated.  It's an input filter.  Output filters sees EOS.

You're right in that HTTP_IN should have the logic, but you're
wrong (IMHO) on whether it should read it.  It can't.  -- justin

View raw message