httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: SSL support
Date Sun, 04 Feb 2001 18:03:13 GMT

> > 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.  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);

    output_data = apr_create_brigade(c->pool);
    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.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message