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 06:42:55 GMT

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

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

HTTP_IN knows about the HTTP protocol, no other filter does.  That is why
it can determine when an EOS is appropriate, and when one isn't.  Any
other filter shouldn't have to worry about the actual protocol that is
being used.

When we designed HTTP_IN, we had to deal with the fact that there is
nothing to signify when the data in a request went from being a request
body to being the beginning of the next request (i.e. headers).  The
HTTP_IN filter takes knowledge from the conn_rec to determine this.

The problem with using multiple fetches of empty brigades, is that we
could be on a very slow link, where we are trickling data, but we don't
know that.  The EOS on input filters is probably not as clean as it is on
output filters.  The general idea is that the only filter/generator that
really knows when the data is done, is the filter/generator that is
actually creating the data.  The EOS buckets keep other filters from
needing to think about what they are doing, because the one filter that
really understands the protocol/data tells the filter when all the data
has been sent.  This also keeps us from having to go through the stack
multiple times.  Take the case of CGI scripts, with CGI scripts, we create
a simple brigade, one pipe bucket and one EOS.  We go down the stack once,
and never think about that request again.


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

View raw message