ap_discard_request_body Re: cvs commit: httpd-2.0 STATUS

[Brian Pane <br...@cnet.com>]

Ryan Bloom wrote:

>For the limits stuff, we need to decide if we want to return 413 if the
>server doesn't care about the request.  For example, default_handler
>always just discards the request body, so is it an error if the user
>sends 100 Meg of data with a request that is just going to ignore it?
>Probably, and if that is the case, then ap_discard_request_body has to
>stay in all of the handlers.
>

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.

Assuming there's nothing else that breaks, I really like the idea
of simplifying the handlers' responsibilities by saying that only
the default_handler has to worry about discarding the request
body.

--Brian

Re: ap_discard_request_body

[Justin Erenkrantz <je...@apache.org>]

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

Re: ap_discard_request_body

[Ryan Bloom <rb...@ntrnet.net>]

On Thu, 6 Jun 2002, Greg Stein wrote:

> On Thu, Jun 06, 2002 at 05:10:58PM -0700, Brian Pane wrote:
> > Ryan Bloom wrote:
> > 
> > >For the limits stuff, we need to decide if we want to return 413 if the
> > >server doesn't care about the request.  For example, default_handler
> > >always just discards the request body, so is it an error if the user
> > >sends 100 Meg of data with a request that is just going to ignore it?
> > >Probably, and if that is the case, then ap_discard_request_body has to
> > >stay in all of the handlers.
> > 
> > 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.
> 
> > Assuming there's nothing else that breaks, I really like the idea
> > of simplifying the handlers' responsibilities by saying that only
> > the default_handler has to worry about discarding the request
> > body.
> 
> Huh? If you say "the handlers' responsibilities", then (by definition) the
> default handler is NOT going to be run.
> 
> 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, it won't be the HTTP_IN filter, because that filter will never be
called unless something in the core calls it, but I can commit the code to
remove this logic from the handlers tonight sometime.

Thanks for the feedback.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------

Re: ap_discard_request_body

[Greg Stein <gs...@lyra.org>]

On Thu, Jun 06, 2002 at 05:10:58PM -0700, Brian Pane wrote:
> Ryan Bloom wrote:
> 
> >For the limits stuff, we need to decide if we want to return 413 if the
> >server doesn't care about the request.  For example, default_handler
> >always just discards the request body, so is it an error if the user
> >sends 100 Meg of data with a request that is just going to ignore it?
> >Probably, and if that is the case, then ap_discard_request_body has to
> >stay in all of the handlers.
> 
> 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.

> Assuming there's nothing else that breaks, I really like the idea
> of simplifying the handlers' responsibilities by saying that only
> the default_handler has to worry about discarding the request
> body.

Huh? If you say "the handlers' responsibilities", then (by definition) the
default handler is NOT going to be run.

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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/