httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 16:04:04 GMT

> I'm not sure I agree with this design point.  
> 
> What is the purpose other than avoiding ap_get_client_block() from
> having to hold onto extra data?

The purpose is to avoid one filter from having to push data back to
another filter.  This goes back to the fact that if we get too much data
in ap_get_client_block, then we are all of a sudden reading the next
request.  That is unacceptable.  It isn't a question of
ap_get_client_block having to hold the extra data, it is a question of
get_client_block being the thing that understands the protocol, and
enforcing our abiding by the protocol.

> A filter may want to give a bucket with indeterminate length (e.g., a
> pipe bucket) to the caller.  How do we the limit the amount of data in
> this case?

This isn't allowed at all.  The thing is, ap_get_client_block KNOWS how
much data it can expect.  It knows this because there are headers that
tell it "here is how much data is in the body" or "here is how much data
is in this chunk of the body".  If ap_get_client block gets more than that
amount of data, then there is the real possability that we will read past
the end of the request.

> It seems better that filters deliver data in amounts which make sense
> to them.  In the case that the receiving filter can't deal with all of
> it, the receiving filter (or ap_get_client_block() in this basket
> case) will have to save it aside.

How do you know when you have hit the end of the request?  There are only
three solutions.

1)  Implement an all-knowing filter
2)  Allow push-back from one filter to another
3)  Specify the max amount of data allowed to be read.

1 won't be maintainable into the future.  

2 is a scary design, because it allows two filters access to the same
brigade at the same time.  Sooner or later, we will clobber data that way.

3 is what we are implementing.  Basically saying, http_filter understands
two modes, but not when we are in each mode.  We tell http_filter which
mode we are in by the arguements we pass to it.  This is just like using
c->remaining, except it is safer.

> While there are cases other than ap_get_client_block() when the caller
> of ap_get_next_brigade() is likely not to be able to use everything
> that comes back, often it is hard for a caller of ap_get_next_brigade()
> to tell the other filter how much it can take in terms of bytes, as
> whether or not anything would be "left over" depends on how/if the
> received data has to be transformed.

But that's fine.  Let's take an actual example, the gunzip
filter.  Ap_get_client_block says I want exactly 50 bytes of data, and it
calls gunzip with that information.  gunzip can request all the data
available at the time (it does this with AP_GET_ANY_AMOUNT [in my current
patch]).  Gunzip just can't return more than the 50 bytes it was asked
for.  It can buffer as much as it wants, assuming it is willing to take
responsability for not breaking the protocol.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message