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 18:59:48 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?
> 
> > But why can't I just write it to the next filter in the normal way,
> > instead of direct to the socket? That is, write to the next _output_
> > filter from my _input_ filter?
> 
> A couple of things.  When we are reading data for the request, we don't
> have enough information about the request to have actually setup the
> entire output filter stack.  For example, we don't actually have the
> information to know if we are chunking or doing byteranges.
> 
> At the level you are at, of course you don't care about that stuff.

Damn. I was halfway through answering the previous paragraph when I read
this! Exactly so.

>  It
> would be possible for you to do the following, although for most filters
> it is unadvisable unless you really understand what is happening:
> 
> ssl_input_filter(f, bb)
> {
>     conn_rec *c = f->c;
>     apr_bucket_brigade *output_data;
>     ap_filter *output_filters = c->output_filters;
> 
>     b = AP_BRIGADE_FIRST(bb);
>     apr_bucket_read(bb);
> 
>     output_data = apr_create_brigade(c->pool);
>     create_output_data(output_data);
>     ap_pass_brigade(output_data, output_filters);
> }
> 
> This only works because you know where you are when executing your
> filter.  This will potentially cause some problems when you are reading
> request data, because you have no idea how much of the actual filter stack
> has been setup, nor which connection filters are currently in place.

??? Surely an input filter reads when its asked to? I suspect we can get
away with reading (as far as upper layers are concerned) only when
asked, but writing at various other moments, too.

I have to admit that I'm less familiar with input filters than output
ones at this time - is there a nice simple example? Should I write one?

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