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 20:56:27 GMT wrote:
> On Mon, 19 Feb 2001, Ben Laurie wrote:
> > wrote:
> > >
> > > > In fact, in mod_tls, I should not assume that the underlying filter is
> > > > socket, so I shouldn't be testing for EOF anyway - I should simply
> > > > return EOS when the brigade is empty.
> > >
> > > You should never return EOS.  EOS is a bucket type, and it must come from
> > > the lowest level possible.  If you are reading from the socket, then you
> > > should add an EOS bucket to the brigade once you have read all the data.
> >
> > 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.

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

It seems to me that it should be a design aim to avoid such magical

And I'm, once more, completely confused about what should be happening
when the socket hits EOF in the blocking and non-blocking cases!

Actually, it would help my understanding if someone would define in a
protocol neutral way precisely what EOS means.




"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