You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 2001/02/03 21:13:20 UTC
SSL support
OK, I'm not going to wait around for someone else to take the lead any
more - so I've started work on mod_tls (name chosen to avoid confusion).
I intend to check stuff in as soon as I have it working even a little -
this is going to be a group activity :-)
However, I've immediately hit a problem - SSL requires the ability to
write when its reading and read when its writing, if you see what I
mean. Now, I really wanted to slot it in as a filter, which means that
the read filter has to be able to send stuff to the write filter chain
(well, insert stuff, more to the point) and vice versa. I can't
immediately see how that's possible, if it is at all. Is it? Should it
be?
A fallback position would be to replace the bottom (i.e. socket) layer,
but I'd rather avoid that if I can - however, if the answer to the above
is "forget it", then I guess I need to know how one does that (I haven't
looked, so just kick me if its obvious).
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
Re: SSL support
Posted by Jon Travis <jt...@covalent.net>.
On Sun, Feb 04, 2001 at 02:03:05PM +0000, Ben Laurie wrote:
> Jon Travis wrote:
> >
> > On Sat, Feb 03, 2001 at 08:13:20PM +0000, Ben Laurie wrote:
> > > OK, I'm not going to wait around for someone else to take the lead any
> > > more - so I've started work on mod_tls (name chosen to avoid confusion).
> > > I intend to check stuff in as soon as I have it working even a little -
> > > this is going to be a group activity :-)
> > >
> > > However, I've immediately hit a problem - SSL requires the ability to
> > > write when its reading and read when its writing, if you see what I
> > > mean. Now, I really wanted to slot it in as a filter, which means that
> > > the read filter has to be able to send stuff to the write filter chain
> > > (well, insert stuff, more to the point) and vice versa. I can't
> > > immediately see how that's possible, if it is at all. Is it? Should it
> > > be?
> > >
> > > A fallback position would be to replace the bottom (i.e. socket) layer,
> > > but I'd rather avoid that if I can - however, if the answer to the above
> > > is "forget it", then I guess I need to know how one does that (I haven't
> > > looked, so just kick me if its obvious).
> >
> > Why not just replace the standard socket bucket with a new SSL socket
> > bucket. And add output filters to send that data back out the pipe?
> > I don't think this needs to be implemented as a read filter.
>
> You've lost me - why would I need to replace the socket bucket _and_ add
> an output filter? How come I need an output filter and not an input one?
Because the buckets are read from and not written to. We can disregard
this dicussion though, because I believe that the 2 filtered approach
will be much better, and definitely more modular.
-- Jon
Re: SSL support
Posted by Ben Laurie <be...@algroup.co.uk>.
Jon Travis wrote:
>
> On Sat, Feb 03, 2001 at 08:13:20PM +0000, Ben Laurie wrote:
> > OK, I'm not going to wait around for someone else to take the lead any
> > more - so I've started work on mod_tls (name chosen to avoid confusion).
> > I intend to check stuff in as soon as I have it working even a little -
> > this is going to be a group activity :-)
> >
> > However, I've immediately hit a problem - SSL requires the ability to
> > write when its reading and read when its writing, if you see what I
> > mean. Now, I really wanted to slot it in as a filter, which means that
> > the read filter has to be able to send stuff to the write filter chain
> > (well, insert stuff, more to the point) and vice versa. I can't
> > immediately see how that's possible, if it is at all. Is it? Should it
> > be?
> >
> > A fallback position would be to replace the bottom (i.e. socket) layer,
> > but I'd rather avoid that if I can - however, if the answer to the above
> > is "forget it", then I guess I need to know how one does that (I haven't
> > looked, so just kick me if its obvious).
>
> Why not just replace the standard socket bucket with a new SSL socket
> bucket. And add output filters to send that data back out the pipe?
> I don't think this needs to be implemented as a read filter.
You've lost me - why would I need to replace the socket bucket _and_ add
an output filter? How come I need an output filter and not an input 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
Re: SSL support
Posted by Jon Travis <jt...@covalent.net>.
On Sat, Feb 03, 2001 at 08:13:20PM +0000, Ben Laurie wrote:
> OK, I'm not going to wait around for someone else to take the lead any
> more - so I've started work on mod_tls (name chosen to avoid confusion).
> I intend to check stuff in as soon as I have it working even a little -
> this is going to be a group activity :-)
>
> However, I've immediately hit a problem - SSL requires the ability to
> write when its reading and read when its writing, if you see what I
> mean. Now, I really wanted to slot it in as a filter, which means that
> the read filter has to be able to send stuff to the write filter chain
> (well, insert stuff, more to the point) and vice versa. I can't
> immediately see how that's possible, if it is at all. Is it? Should it
> be?
>
> A fallback position would be to replace the bottom (i.e. socket) layer,
> but I'd rather avoid that if I can - however, if the answer to the above
> is "forget it", then I guess I need to know how one does that (I haven't
> looked, so just kick me if its obvious).
Why not just replace the standard socket bucket with a new SSL socket
bucket. And add output filters to send that data back out the pipe?
I don't think this needs to be implemented as a read filter.
-- Jon
Re: SSL support
Posted by rb...@covalent.net.
> > 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.
Input filters read when ap_get_brigade is called, so when reading headers
and when calling get_client_block. The former is safe, the latter could
be called by and handler however, and thus we really no longer know what
the filter stack looks like.
> 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?
Take a look at www.ntrnet.net/~rbb. Look for mod_apachecon. This is a
VERY simple input filter that just reads looking for the first line of a
request. Then it just goes through and replaces \ with / and ' ' with %20
in the URI. That is the simplest we get. For more detailed examples,
look in http_protocol for the HTTP_IN filter.
I'm leaving for the day, I'll be back at my computer later tonight though.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SSL support
Posted by Ben Laurie <be...@algroup.co.uk>.
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
input filters / getline (was: Re: SSL support)
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 04, 2001 at 04:53:19PM -0800, rbb@covalent.net wrote:
> > > I think it's a bad design :-) ... but am not ready to spend the time on it
> > > to suggest an alternative. IMO, the input filters should always read chunks
> > > of data. The upper filters can massage that into lines, if that is what is
> > > needed.
> >
> > Right. The obvious way out of this is to provide general purpose brigade
> > masseurs (or masseuses) that will give you a line from a chunky brigade.
> > But perhaps I'm missing something.
>
> What you are missing is how to get the data back to the lower
> filter. Right now, filters are one way, if we have a set of functions
> that break data, we need to send that data back to the bottom of the
> filter chain, otherwise it won't be there for the next request.
The key here being that if a *request* input filter reads in a chunk,
extracts a line, determines "end of request", then how does it get it put
back for the next request to deal with it?
[ it can't just cache it for later ]
This (presumably) isn't a problem for connection filters.
[ since these *can* cache it for the next request to read ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SSL support
Posted by rb...@covalent.net.
> > I think it's a bad design :-) ... but am not ready to spend the time on it
> > to suggest an alternative. IMO, the input filters should always read chunks
> > of data. The upper filters can massage that into lines, if that is what is
> > needed.
>
> Right. The obvious way out of this is to provide general purpose brigade
> masseurs (or masseuses) that will give you a line from a chunky brigade.
> But perhaps I'm missing something.
What you are missing is how to get the data back to the lower
filter. Right now, filters are one way, if we have a set of functions
that break data, we need to send that data back to the bottom of the
filter chain, otherwise it won't be there for the next request.
> > But there is also the caveat of HTTP being line-oriented and not wanting to
> > read too far (past the newline). So yes, I recognize that is the cause of
> > the current design, but I still don't have to like it :-)
>
> Protocol is supposed to be pluggable, remember.
Remember that the line vs chunk oriented is based on a field in the
conn_rec. The protocol can control whether it gets line-oriented or
chunk-oriented data from the filters. IMHO, we will always need to allow
a protocol to specify what kind of data they currently expect.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SSL support
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> On Sun, Feb 04, 2001 at 01:51:04PM -0800, rbb@covalent.net wrote:
> >...
> > Yeah, but not really. What we are really saying here is that input
> > filters in general have two modes, read one line and read a big chunk. It
> > is a bit bogus, but that is just how it has to work. The fact that
> > ap_http_filter is next is also not exactly true, we just know that
> > ap_http_filter is later in the chain, so it controls how much data we get
> > back. It is more a bad comment than a bad design.
>
> I think it's a bad design :-) ... but am not ready to spend the time on it
> to suggest an alternative. IMO, the input filters should always read chunks
> of data. The upper filters can massage that into lines, if that is what is
> needed.
Right. The obvious way out of this is to provide general purpose brigade
masseurs (or masseuses) that will give you a line from a chunky brigade.
But perhaps I'm missing something.
Might be one for the Hackathon...
> But there is also the caveat of HTTP being line-oriented and not wanting to
> read too far (past the newline). So yes, I recognize that is the cause of
> the current design, but I still don't have to like it :-)
Protocol is supposed to be pluggable, remember.
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
Re: SSL support
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 04, 2001 at 01:51:04PM -0800, rbb@covalent.net wrote:
>...
> Yeah, but not really. What we are really saying here is that input
> filters in general have two modes, read one line and read a big chunk. It
> is a bit bogus, but that is just how it has to work. The fact that
> ap_http_filter is next is also not exactly true, we just know that
> ap_http_filter is later in the chain, so it controls how much data we get
> back. It is more a bad comment than a bad design.
I think it's a bad design :-) ... but am not ready to spend the time on it
to suggest an alternative. IMO, the input filters should always read chunks
of data. The upper filters can massage that into lines, if that is what is
needed.
But there is also the caveat of HTTP being line-oriented and not wanting to
read too far (past the newline). So yes, I recognize that is the cause of
the current design, but I still don't have to like it :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SSL support
Posted by rb...@covalent.net.
> > > 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.
> */
Yeah, but not really. What we are really saying here is that input
filters in general have two modes, read one line and read a big chunk. It
is a bit bogus, but that is just how it has to work. The fact that
ap_http_filter is next is also not exactly true, we just know that
ap_http_filter is later in the chain, so it controls how much data we get
back. It is more a bad comment than a bad design.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SSL support
Posted by Ben Laurie <be...@algroup.co.uk>.
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
Re: SSL support
Posted by rb...@covalent.net.
> > 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);
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SSL support
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > > > However, I've immediately hit a problem - SSL requires the ability to
> > > > write when its reading and read when its writing, if you see what I
> > > > mean. Now, I really wanted to slot it in as a filter, which means that
> > > > the read filter has to be able to send stuff to the write filter chain
> > > > (well, insert stuff, more to the point) and vice versa. I can't
> > > > immediately see how that's possible, if it is at all. Is it? Should it
> > > > be?
> > >
> > > I don't understand what you want to do. Do you want to write something to
> > > the socket as you are reading, or do you want to setup some data to be
> > > written as you start to write the output?
> > >
> > > If the latter, just delay inserting the output_filter until you are in the
> > > input filter, and then you can insert the output filter with a ctx pointer
> > > that has the data you want to write.
> >
> > Unfortunately, its the former :-) And vice versa (hmm ... just possibly
> > we can get away with not doing this variant, actually). And it goes on
> > all the time, not just at startup.
>
> 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.
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?
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
Re: SSL support
Posted by rb...@covalent.net.
> > > However, I've immediately hit a problem - SSL requires the ability to
> > > write when its reading and read when its writing, if you see what I
> > > mean. Now, I really wanted to slot it in as a filter, which means that
> > > the read filter has to be able to send stuff to the write filter chain
> > > (well, insert stuff, more to the point) and vice versa. I can't
> > > immediately see how that's possible, if it is at all. Is it? Should it
> > > be?
> >
> > I don't understand what you want to do. Do you want to write something to
> > the socket as you are reading, or do you want to setup some data to be
> > written as you start to write the output?
> >
> > If the latter, just delay inserting the output_filter until you are in the
> > input filter, and then you can insert the output filter with a ctx pointer
> > that has the data you want to write.
>
> Unfortunately, its the former :-) And vice versa (hmm ... just possibly
> we can get away with not doing this variant, actually). And it goes on
> all the time, not just at startup.
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SSL support
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > However, I've immediately hit a problem - SSL requires the ability to
> > write when its reading and read when its writing, if you see what I
> > mean. Now, I really wanted to slot it in as a filter, which means that
> > the read filter has to be able to send stuff to the write filter chain
> > (well, insert stuff, more to the point) and vice versa. I can't
> > immediately see how that's possible, if it is at all. Is it? Should it
> > be?
>
> I don't understand what you want to do. Do you want to write something to
> the socket as you are reading, or do you want to setup some data to be
> written as you start to write the output?
>
> If the latter, just delay inserting the output_filter until you are in the
> input filter, and then you can insert the output filter with a ctx pointer
> that has the data you want to write.
Unfortunately, its the former :-) And vice versa (hmm ... just possibly
we can get away with not doing this variant, actually). And it goes on
all the time, not just at startup.
> > A fallback position would be to replace the bottom (i.e. socket) layer,
> > but I'd rather avoid that if I can - however, if the answer to the above
> > is "forget it", then I guess I need to know how one does that (I haven't
> > looked, so just kick me if its obvious).
>
> One doesn't. :-) It should be perfectly possible to create an SSL module
> that is a filter.
That's what I want to achieve.
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
Re: SSL support
Posted by rb...@covalent.net.
> However, I've immediately hit a problem - SSL requires the ability to
> write when its reading and read when its writing, if you see what I
> mean. Now, I really wanted to slot it in as a filter, which means that
> the read filter has to be able to send stuff to the write filter chain
> (well, insert stuff, more to the point) and vice versa. I can't
> immediately see how that's possible, if it is at all. Is it? Should it
> be?
I don't understand what you want to do. Do you want to write something to
the socket as you are reading, or do you want to setup some data to be
written as you start to write the output?
If the latter, just delay inserting the output_filter until you are in the
input filter, and then you can insert the output filter with a ctx pointer
that has the data you want to write.
> A fallback position would be to replace the bottom (i.e. socket) layer,
> but I'd rather avoid that if I can - however, if the answer to the above
> is "forget it", then I guess I need to know how one does that (I haven't
> looked, so just kick me if its obvious).
One doesn't. :-) It should be perfectly possible to create an SSL module
that is a filter.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------