httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [PATCH] mod_ssl input filtering...
Date Sat, 06 Oct 2001 04:26:47 GMT
From: "Greg Stein" <gstein@lyra.org>
Sent: Friday, October 05, 2001 11:14 PM


> On Fri, Oct 05, 2001 at 03:39:47PM -0700, Ryan Bloom wrote:
> > On Friday 05 October 2001 03:34 pm, William A. Rowe, Jr. wrote:
> > 
> > > And the more that I look at this, the more we need a push-back model,
> > > because the scope of 'this' filter doesn't live as long as the parent
> > > filter (with request and connection scopes, respectively.)
> > 
> > A push-back model is not needed.  A filter should not be passing back more
> > data than the parent can use for this request.  If we need to push data back,
> > then there is a problem.  When asks for X bytes of data, it is taking 
> > responsibility for using all X bytes.
> 
> I *strongly* agree with Ryan here. Pushback is *not* needed.

I am begining to accept this may be true.  I expect in a few months to prove
that it was (is still) needed, but not today :)

> If filters want to have a read mode of "give me a 'nice' amount", then that
> is a separate question. (and the HTTP_IN will determine 'nice' based on
> request boundaries)

Agreed.  It's up to ANY filter to quit it when it just can't handle more data.
So when SSL first queries, it doesn't care if its caller asked for a line, a
certain amount, or a 'nice' amount.  It will query CORE for whatever CORE believes
is a 'nice' amount.  Then it will ask SSL 'is this enough'?  If not, go get more.
If so, split at the caller's limit (one line, n bytes, or whatever it just 
finished processing.)

> But if a filter ever says <X> bytes, then f->next *cannot* ever return more
> than that amount.

We concur.  Here again, I think this is silly, that the code shouldn't be
duplicated in each and every content/body filter, but reside in ap_get_client_block.
Whatever, that's a performance proof for later.

Reducing code complexity... now that's a chuckle, let's have dozens of filters
all implementing (buggy or not) client throttling.  Only three filters today
need to throttle.  Core (ideal frame size?  IP knows), SSL (how many more bytes
till we hit the next decodable packet?) and HTTP (chunked or CONTENT_LENGTH
limiting).

I'd like some examples of other filters that can reasonably be expected to
throttle the filtered bytes.  I really don't see the rational.  If anyone
needs a throttle, I'd expect we could do that once, correctly, right there
in ap_get_client_block, instead of within EVERY data-expanding filter.

> IMO, we ought to fix mod_ssl and proxy before worrying about optimizing for
> "return a nice amount".

6/1, 6/!1 ... It's actually a better use for first-packets to mod_ssl, and
I'll let proxy folks tell us what's good for them.  Funny, noone actually 
listens to filter authors.  Really be interested in Jeff's opinions here,
since he's the only other input filter author I can think of, besides Ben 
(too busy) and Ryan (too quiet).  Them and all those SSL hackers.

Heck, any mod_perl input filter examples yet, Doug :-?

Bill



Mime
View raw message