httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: socket_read?
Date Tue, 20 Feb 2001 20:48:03 GMT
rbb@covalent.net wrote:
> 
> On Tue, 20 Feb 2001, Ben Laurie wrote:
> 
> > rbb@covalent.net wrote:
> > >
> > > > > > Actually, it would help my understanding if someone would define
in a
> > > > > > protocol neutral way precisely what EOS means.
> > > > >
> > > > > I'll do my best, but my words are probably wrong.  Filters are run
at
> > > > > specific times when processing.  An EOS means that there will be
NO MORE
> > > > > data down that filter stack, EVER.  There could be more than one
filter
> > > > > stack per request, but the filter stack is only valid until in receives
an
> > > > > EOS bucket.
> > > >
> > > > These words work perfectly for me. It does leave open a deeper question
> > > > about the creation/recreation of filter stacks, but I can live with that
> > > > being open for now.
> > >
> > > May as well explore this now rather than later.  :-)  Could you try to
> > > phrase the question so that we can all discuss it.  I don't want to try to
> > > figure out what you are thinking, and get it wrong.
> >
> > I'm not sure I can, because it isn't really fully formed in my mind, but
> > it is basically to do with STARTTLS - in a protocol which uses that
> > (which is most), the TLS layer needs to be inserted and removed from the
> > filter stack on the fly. The issue being that you may need to preserve
> > brigades (through preserving filters, I presume) whilst rebuilding the
> > stack.
> 
> It is perfectly okay to add and remove filters from a filter stack on the
> fly.  That should just work.  I guess we'll see as you do the work.  :-)

The problem that concerns me is this ... suppose that we have a protocol
that's pipelined and switches into TLS for a while. Imagine what happens
when it switches out of TLS and sends some more plaintext stuff - the
TLS filter reads the last TLS packets and is left with some plaintext.
The filter then wants to be removed - what does it do with this
lingering data? It can't push it up the stack (that requires a call from
above) and it can't push it down the stack (as I understand it). So the
only thing I can imagine that works now is for it to stick around until
the data has been eaten. This is not so easy to fit with the idea of
some outside agency determining the current filter stack (that decision
will probably happen several layers up).

BUT!!! can we please get closure on the EOS/EOF question before we even
get into this? Who's going to hack the code?

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