> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > 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() path > > that actually solves the problem. Until you create a set of functions > > 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 to > > 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, > APR_BLOCK_READ, > YOUR_PREFERRED_CHUNK_SIZE); > if (rv != APR_SUCCESS) { > /* something bad happened */ > } > APR_BRIGADE_FOREACH(e, bb) { > 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? Ryan
