httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: SSL support
Date Sun, 04 Feb 2001 19:05:09 GMT
rbb@covalent.net wrote:
> 
> > > Okay, so why can't you just do that.  What I mean is something like the
> > > following in your input filter (and conversly in the output filter)
> > >
> > > apr_status_t ssl_input_filter(ap_filter_t *f, apr_brigade *bb)
> > > {
> > >
> > >     ap_bucket *b = APR_BRIGADE_LAST(bb);
> > >     ap_bucket_socket *bs = b->data;
> > >
> > >
> > >     if (APR_BUCKET_IS_SOCKET(b)) {
> > >         ap_bucket_read(...);
> > >         apr_send(bs->socket, ...);
> > >     }
> > > }
> > >
> > > The idea is above, but the names are almost definately wrong.
> > >
> > >  You are
> > > writing a filter at a level low-enough that you will need to actually get
> > > information out of the bucket itself.
> >
> > I was noticing as I went along all these filters that know stuff about
> > the next/previous filter in the chain. I can't say I'm very keen on
> > that.
> 
> You shouldn't know anything about the next/prevous filter unless you are
> the last or the first filter.  In those cases, you know that you are
> either responsible for generating data, or for reading from/writing to the
> network.  Anything else that you know is something that your module needed
> to discover for itself.  What is it that you know about the next/previous
> filter that you dislike?

For example, from ap_dechunk_filter:

            /* Time to read another chunk header or trailer... 
ap_http_filter() is 
             * the next filter in line and it knows how to return a
brigade with 
             * one line.
             */
 
Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message