httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: socket_read?
Date Tue, 20 Feb 2001 05:22:55 GMT
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 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.

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.

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

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

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



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

View raw message