httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Fri, 13 Oct 2000 00:11:49 GMT
On Thu, Oct 12, 2000 at 04:57:27PM -0700, wrote:
> I'll be working backwards, because I think it will make more sense.  Take
> the gunzip filter.  The content length tells Apache when to stop reading
> data from the network.  Greg, in what you said above, we end up losing
> data.  It is a sneaky loss, but it exists.  Think about it this way.  We
> start with a content length of 25.  This is 25 bytes of gzip'ed data that
> actually represents 35 bytes.  We start by calling down through
> gunzip_filter to the http_filter, saying give back at most 25 bytes.  The
> http_filter gives 25 bytes to the gunzip filter, which uncompresses to 35
> bytes.  Now the gunzip filter is only allowed to return 25 bytes, leaving
> 10 that are saved off to the side.  The problem is that as far as Apache
> is concerned, we have already read all the data from the network,

BING! There is your error :-)

"as far as Apache is concerned" ?? Nope. We have only read all the data from
the network when the top filter on input_filters() returns APR_EOF. Don't
look in any magic fields of the request or conn_rec. Wait for APR_EOF.

[ the underlying filters will manage when to send APR_EOF ]

ap_get_client_block() shouldn't look at any fields in the request or conn to
determine when "end" is. The only definition of "end" is APR_EOF.

Caveat: we may need to distinguish APR_EOF -- between "socket closed" and
"end of this request" ... I haven't thought about that part yet.

Net result: we don't lose data.

> What else does this mean?  It means that all of a sudden
> ap_get_client_block can actually receive more data from the filters than
> it asked for.

Nope. This would still be restricted to what ap_get_client_block() asked
for, from the top input filter. *That* filter may need to do some set-aside,
but that isn't get_client_block's concern.

> The filters can't read more from the network than they were
> told to, but they can transform the data into a larger chunk of data.  So,
> we will need to be able to save the extra data from the filters.  To do
> this, we don't want to use the conn_rec, because this is request data, so
> we will need a brigade in the request_rec.

Nope. Go back, young man :-)

> I dislike this, and there is a big part of me that thinks we are violating
> the HTTP protocol by allowing filters to expand the body data like
> this.  The other thing that needs to be noted, is that if we change the
> content-length, then that information also needs to be changed in the
> request_rec.

1) we aren't violating HTTP. it was designed for this kind of expansion.

2) don't put content-length into the request_rec. that is a private matter
   for the chunk_filter, I believe. (not sure who's responsible if the chunk
   filter isn't installed; but I know that we should not be changing the
   value sitting in the request_rec (nobody should examine that value!).


Greg Stein,

View raw message