On Friday 05 October 2001 12:21 pm, Justin Erenkrantz wrote: > Yup, that's what I was thinking. =) > > Now, what about the case that we want to do a blocking read but we > don't really know how much to read? I think it is analogous to the > non-blocking case (what this commit does), but it just calls > bucket_read with a timeout value. Whatever it returns should be > good enough. We can't rely on apr_brigade_partition since it must > block.
We shouldn't be using brigade_partition in this case. Brigade partition should only be called from the filter code if we already have a brigade that won't block. In other words, if the core input filter is using brigade_partition, that is the cause of the bug reports about the length of serving POST requests. > So, I'm thinking a new ap_get_brigade mode called > AP_BLOCKING_PARTIAL_MODE might do the trick. It tells the core input > filter that it is okay to return less than that number of bytes. It > issues *one* blocking read and returns at most *readbytes (or len > returning from bucket_read if smaller) back in the brigade. I think > this would make mod_ssl much happier. =) Nope. The filters should always been in this mode. A filter should never wait until it has all of the data that was requested before it returns. A filter that is called with blocking mode does NOT mean that it must fulfill the entire request, it just means that it must have at least one byte of data. This is the same way that blocking reads work with sockets, and filters should work the same way. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
