On Mon, Sep 24, 2001 at 11:58:40AM -0700, Justin Erenkrantz wrote:
> On Mon, Sep 24, 2001 at 01:32:02AM -0700, Greg Stein wrote:
> > Eww. No... just move the filter back to the connection and you're fine. We
> > can make it a request filter later on.
>
> Actually, you can't make it a connection-based filter because there
> is no way to retrieve any request information (such as determining
> what the body type is) from a connection filter. So, we can't merge
> dechunk and http_in unless we have access to the current request.
> This means that HTTP_IN must be a request filter in order to get it
> to understand HTTP.
Hmm. All right...
> What is the problem with using the pool's userdata? I don't see
> the "Eww" that you guys do. Or, what is the problem with getting
> the socket to behave appropriately (i.e. I want 10 bytes, give me
> 10 not 8192)?
It is a hack. I see it as using the userdata as a global variable. You drop
off some data and go pick it back up later on. The code and data flow is
obtuse and non-obvious. When somebody sees the read or write to the
userdata, they're going to go, "what is going on?"
> The brigades should not be returning more data than is asked for
> ever.
Fix the wording: not the brigades but the *filters*.
And yes: I totally agree. I've said that a few times recently :-) I was just
hoping that your patch could be done independently of the limiting thing.
And that we could go fix the limited-return in a future step.
> What happens then is that we now enter a condition where the
> caller may not be able to handle the data (i.e. I only wanted 10
> bytes you gave me 8192, oops). This is fundamentally incorrect -
> changing scopes doesn't seem to be the answer. -- justin
All right. If you're willing to tackle the limited return, then that would
seem to be a good first step. The second step would be the patch you just
posted.
IOW, could we get "limited return" first, then the reorg patch second? Or
are the two things too comingled right now?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
