httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: socket_read?
Date Mon, 19 Feb 2001 22:25:20 GMT wrote:
> On Mon, 19 Feb 2001, Ben Laurie wrote:
> > wrote:
> > >
> > > On Mon, 19 Feb 2001, Ben Laurie wrote:
> > >
> > > > wrote:
> > > > >
> > > > > > In fact, in mod_tls, I should not assume that the underlying
filter is a
> > > > > > socket, so I shouldn't be testing for EOF anyway - I should
> > > > > > return EOS when the brigade is empty.
> > > > >
> > > > > You should never return EOS.  EOS is a bucket type, and it must come
> > > > > the lowest level possible.  If you are reading from the socket, then
> > > > > should add an EOS bucket to the brigade once you have read all the
> > > >
> > > > This is not compatible with previous theories! If a socket bucket is in
> > > > the middle of a stream of other buckets, then returning an EOS would be
> > > > wrong, wouldn't it?
> > >
> > > My bad, again, words not meaning.  When I said socket, I meant a filter
> > > that is actually at the lowest level, not one that is necessarily reading
> > > from a socket bucket.  In the HTTP case, the lowest level filter is the
> > > core_input filter.  It creates two buckets, one socket and one EOS.  The
> > > HTTP_IN_FILTER reads from the socket until it sees either an EOF, or where
> > > it is supposed to stop reading, and then it adds the EOS.  In this case,
> > > the HTTP_IN_FILTER knows enough about what it is doing to know when an EOS
> > > is needed.
> >
> > Actually, when mod_tls is active, the HTTP_IN_FILTER does _not_ have a
> > socket underneath, and, hence, should not rely on having one.
> >
> > Should mod_tls emulate a socket? Well, if it must, but that seems
> > undesirable to me.
> That is the bug.  When we wrote the HTTP_IN_FILTER, we assumed (probably
> incorrectly), that it would read from a socket directly.  We will need to
> fix that filter, not yours.  Could you post exactly what you are seeing.
> If I get a chance tomorrow, I will look into fixing that filter.

The problem is a theoretical one - despite my concerns it does actually
work (perhaps this should worry me :-). What I'm trying to achieve is
clearly defined behaviour so we can be sure it works in all cases, and
continues to work in the future and with other protocols.

> > > > > If you are reading from a brigade, then you should only ever see
an EOS
> > > > > bucket if the lower level filter gave you one.
> > > >
> > > > This makes it impossible to mix a socket or pipe bucket in a brigade
> > > > with other types, doesn't it?
> > >
> > > Not at all.  EOS means that a lower level filter has generated or read
> > > all of the data for this request.  Why wouldn't you be able to mix socket
> > > or pipe buckets in this case?
> >
> > That was a symptom of my confusion - but my current theory is that my
> > confusion is caused by some filters having magical knowledge.
> >
> > It seems to me that EOS gets generated when something decides that the
> > input stream has come to an end. How the something makes that decision
> > appears to be magical - core_input decides it has at the end of a
> > request _or_ at an EOF - the first is non-magical, because its based in
> > the input. The second seems like a problem to me: how does it know there
> > isn't another bucket in the brigade (OK, it could test for this, but
> > does it?) or that there isn't another brigade that would follow if it
> > asked for it?
> Core_input doesn't really do anything.  It just creates two buckets in a
> single brigade, socket and EOS.  It then passes this up the stack.
> HTTP_IN does a bunch of magic.  This is where the filter either adds an
> EOS based on end of request or EOF.  The second is wrong, and needs to be
> fixed.

OK, I'm with you there.

> > It seems to me that it should be a design aim to avoid such magical
> > knowledge.
> That should be and is the goal.


> > And I'm, once more, completely confused about what should be happening
> > when the socket hits EOF in the blocking and non-blocking cases!
> IMHO it is really simple.  When a socket hits EOF, it should simply remove
> the socket from the brigade.  Period.  That's it.  The socket_read
> function should never return EOF.  There is no such thing as EOF to a
> filter.  Filters only know about EOS.

Cool. Again, this makes perfect sense to me. It does, incidentally, have
to transmute to an empty bucket, so as not to invalidate the pointer
held at a higher level, but I can live with that (the alternative, which
I can also live with, is to invalidate the pointer, but return an error
that says so, e.g. APR_BUCKET_INVALIDATED - in some ways I prefer this,
but not enough to scream about it).

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


The only problem I'm left with now is that I can't see how HTTP_IN (or a
lower filter?) is going to work out that it needs to insert EOS. Further
to that, if it can work it out from other stuff, why can't all filters
work it out and avoid the need for EOS altogether? My current theory is
that you see that the brigade is empty. You ask for the next brigade.
You discover _that_ is empty, too, and at that point, you're done (and
can insert an EOS - or start returning empty brigades). The only problem
is, I can't see how this works in NONBLOCK - the next brigade _should_
be empty (oooh, or perhaps not, it should contain (at least) a
zero-length bucket - that makes some sort of sense).




"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

View raw message