httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject RE: Filters : mod_ssl (fwd)
Date Wed, 11 Jul 2001 05:44:43 GMT
On Wed, 11 Jul 2001, Cliff Woolley wrote:

> Yes. That is the expected behaviour if a timeout is set. But, I haven't set
> any timeout currently - so the read blocks till it receives some data OR the
> connection is dropped. I verified that the chunk_filter (http_core.c) also
> uses a APR_BLOCK_READ while doing a apr_bucket_read.

Take a look at the code Bill Stoddard just committed to the content length
filter that does one of these nonblocking-eagain-blocking-timeout thingys.

> The reason I had sent out the earlier mail is because of the following set
> of observations :
>
> 1. Once the handshake is completed, the module should now get the client
> data - thru' the apr_bucket_read(). There seems to be no data in the bucket,
> which is why the read just blocks - where is the client data ?.

Well, if any data arrived within the timeout period, it should be in the
bucket returned from apr_bucket_read().  If you get 0 bytes back and
success, move on to the next bucket (which will probably be an EOS bucket
in this case).

> 2. As regards the output brigade (pbbOut), I'm confused - don't we need
> something like APR_BRIGADE_INSERT_HEAD here ?. I'm still trying to learn
> filters / brigades - so, please pardon my ignorance here.

In which spot?  pbbOut seems to be used (sort of) correctly to me (with
APR_BRIGADE_INSERT_TAIL).  Basically what's going on is that
tls_in_filter() calls churn() which reads one bucket at a time off the
input brigade, churns it, and sticks it on the pending brigade.  Then
churn() returns and tls_in_filter takes one bucket at a time off the front
of the pending brigade and tacks it onto the end of the "output" brigade
which it then passes down the filter chain to the next input filter.

I see two problems (neither fatal, but just generally undesirable):

(1) churn() allocates memory for the churned input data from c->pool,
which is bad.  There's an XXX comment at that spot that asks if it should
be using a heap bucket instead.  The answer is yes.

(2) tls_in_filter() moves one bucket at a time from the pending brigade to
the output brigade, when in fact you can move them all in one fell swoop.
That whole while loop should be replaced with a call to
APR_BRIGADE_CONCAT(), which operates in constant time as opposed to time
linear to the number of buckets in the brigade.

> 3. As per the log output, the OpenSSL handshake happens twice - are we
> losing some client information here ?.

Dunno... perhaps.  Maybe one of the hardcore SSL guys can answer that.
Ralf, Ben, you guys listening?

> 	Also, is there any document which can help me get a detailed
> understanding of filters / bucket brigades..

If you haven't already done so, read through the comments in
apr_buckets.h, which at least briefly describe the general concept.
Various people might have notes lying around that they could give you (I
wouldn't mind having a copy for reference, either, actually).  Ryan gave a
talk on filters at ApacheCon earlier this year and might have some notes
from that, and there was at least one early concept/design document for
bucket brigades (Roy?).  I'd be happy to talk bucket brigades sideband
with you if you'd like, but I don't yet have many written notes about them
yet.  =-)

<shameless plug>
I'm giving a talk at ApacheCon Europe in October about bucket brigades and
Greg Ames and Jeff Trawick are giving one about filters... I hope anyone
interested will be able to attend!
</shameless plug>

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message