httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Fri, 13 Oct 2000 16:40:50 GMT
On Fri, 13 Oct 2000, Greg Ames wrote:
> wrote:
> > 
> >        Passing brigades in two directions may be possible, IFF we use
> > function arguments to pass the brigades.  
> Good.  Sounds like you are starting to open your mind to the possibility
> that there might be more than the One True Solution.

I have always been open to the idea.  I just don't think it can work, and
you and Jeff have not proven otherwise.

> >                  The original
> > patch that you and Jeff created had two filters storing things in the
> > conn_rec structure.  
>                      .....a quick hack to demonstrate the concept,
> inspired by 
> c->input_data, c->remaining, etc...

But that's the problem.  Implement it without two filters storing things
in the same brigade, or at least explain how you would do it.  A quick
hack I don't mind, assuming it is removed at some point, or at least it is
possible to see how it could be removed.  I don't see a way to remove your

> >             But the problem is that it is impossible to know who
> > stored the data there are why.  To do that requires state, which wasn't
> > implemented, and would get ugly quickly.
> I guess we also need to get rid of r->content_type,
> c->input_filters, etc,
> because some night mod_speling might wake up and store the wrong stuff
> there without leaving any tracks.  sheesh....  I'm not going to loose
> any sleep over that one, trust me.

No, and those two things are not even remotely the same.  You had two
filters that were both reading data and saving it to the same place at the
same time.  That just won't work.  Until you have them saving to different
places, I am 100% against this change.  Adding another brigade to the
conn_rec is not a solution either.

> The point is that it is possible to have fields in structures shared
> between multiple pieces of code as long as everybody plays by the
> rules.  And we have the power to make up the rules for new stuff.  Yup,
> information hiding is wonderful because less shared data mean less rules
> to invent/follow, but it can slow you down when you're in prototype
> mode.

But your solution doesn't allow for information hiding.  It requires that
filters be able to share information.

> > The problem with passing data back through arguments, is that you don't
> > know which filters have been called already.  Think of it this way.  We
> > have a gunzip filter, which takes a bunch of compressed body data, and
> > uncompresses it.  Now, a higher filter decides to pass that data back
> > down, if it goes through the uncompress filter, then that filter can stop
> > the pass-back, but wait what if the data need to  go further than the
> > uncompress filter.  
> no, no, NO, no, no...the unget/unread concept works between two adjacent
> filters.  And if the data passed on unread looks any different that the
> data you read (other than having some bytes lopped off the front end),
> you better know what the heck you are doing.  

Please, implement that.  Your patch didn't.  It started to, but it was
incomplete.  The problem as I see it, is that ap_get_client_block knows
when it hits the end of the body.  Currently, no other code in any patch I
have seen knows that information.  the text at the top of your patch says
that if http_filter reads past the end of the body, then it gets put back
in c->raw_data.  Well, if I read this, it says to me that http_filter
reads some data, and it must make it all the way up to
ap_get_client_block.  Then we decide if we read too much.  If we did, we
put it back in c->raw_data.  Unfortunately, this is broken, because by the
time it gets to ap_get_client_block, it has been through multiple filters,
one of which could have seriously screwed up the data.

Until that problem is solved, this patch can't work.  I have said it is a
problem multiple times, and the only response so far has been, it isn't an
issue.  Either explain why it isn't an issue, or implement it and prove

> unread says "Dang! I tried to take a little sip from the fire hose, and
> it just didn't work out for me.  Here's some of your data back."

But by the time you can say that, the water has been heated up, and some
of it has potentially changed into steam.  This design can work, but not
in the current Apache architecture.

> The object of having our favorite length field be a parameter vs. a
> field in the c is information hiding (please correct me if I'm wrong,
> Mr. Stein).  But passing it as a parm to every input filter rather than
> just http_filter isn't hiding the information, is it? 

I don't see it as information hiding.  I see it as information
partitioning.  It isn't that nobody can see the data, the problem is that
logically it doesn't really make any sense for the conn_rec to have that
information.  It is only useful when processing the body of a request, and
that should be solved by using a parameter instead of a field in a


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

View raw message