httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: [PATCH] fix LimitRequestBody for all input handlers
Date Fri, 12 Apr 2002 21:22:03 GMT
> From: Justin Erenkrantz []
> On Fri, Apr 12, 2002 at 01:59:59PM -0700, Ryan Bloom wrote:
> > I have explained three times now that there is no ap_get_brigade()
> > that actually solves the problem.  Until you create a set of
> > that module authors can use to get data from the client, this is the
> > correct solution.  Think of ap_get_client_block as being analogous
> > the handler functions.  Handlers generate content, get_client_block
> > consumes it.
> All a module has to do to get the input data is:
> beginning:
> rv = ap_get_brigade(r->input_filters, bb, AP_MODE_READBYTES,
>                     YOUR_PREFERRED_CHUNK_SIZE);
> if (rv != APR_SUCCESS) {
>    /* something bad happened */
> }
>    if (APR_BRIGADE_IS_EOS(e)) {
>        /* we're done */
>    }
>    apr_brigade_read(e, &mybuf, &mylen);
>    /* Do your stuff to mybuf */
> }
> goto beginning
> You'll get a brigade (bb) that has the input.  When there is nothing
> more (i.e. past C-L or LimitReqBody or whatnot, but you don't need to
> know any of that), you'll either get EOS or an error.  You keep
> looping as you get your data.  This is exactly equivalent to
> ap_get_client_block(), but I believe much more powerful.
> Why wouldn't this work?  All of the chunking, C-L, etc is handled
> by HTTP_IN.  Yes, this means changing the modules to do the right
> thing.  However, I think that should have been done a long time
> ago.  -- Justin

In your code above, there was no 100 Continue sent to the client.  It
also doesn't solve the problem for anybody who is using the
ap_.*client_block API, as most modules do.  Don't tell me that you can
just send the 100 message yourself.  That is a hack.  

Part of what we owe our module authors is a clean API that makes writing
an Apache module easy.  The ap_.*client_block functions are easy to use,
and they can solve the problem easily.  More than that, they are what
people are used to using from Apache 1.3.

We don't allow people to generate content from just any location in an
Apache module, because that doesn't play well with other modules.  Along
the same vein, we should provide a simple set of functions that solve
the problem of consuming data from the client.  In this case, those
functions should continue to be ap.*client_block.

Finally, saying that the 100 Continue message is very module specific,
is incorrect.  In Apache 1.3, every module that was supposed to send a
100 Continue sent it at the correct time.  Why should we make it so much
harder to do so in Apache 2.0?


View raw message