httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [PATCH] daedalus coredump from 2.0.35c
Date Wed, 10 Apr 2002 15:01:16 GMT
> From: gregames@Boron.MeepZor.Com [mailto:gregames@Boron.MeepZor.Com]
On
> 
> Ryan Bloom wrote:
> 
> > The byterange filter requires all of the data from the response
before
> > it can do anything.  If it isn't buffering the data for the
response,
> > then there is a bug.
> 
> Clearly there is a bug.  As I explained, with the current ordering,
the
> byterange filter can take itself out of the chain the first time it is
> called,
> before the true content length is known.

The problem here is that the byterange filter is removing itself before
it should.  Moving it shouldn't actually solve this problem at all.  The
byterange filter should ONLY remove itself if it looks at the request
headers, and there is no Range header at all.

> > Moving the filters around is the wrong solution
> > IMO, because it doesn't solve the problem that the filter is not
working
> > correctly.
> 
> That statement doesn't make much sense to me.  Moving the byterange
filter
> to
> after C-L lets it see the true content length and stay in the filter
> chain,
> which allows it to work correctly in more cases.

The C-L filter calculates the actual C-L in VERY few requests.  The
filter will not compute the C-L unless it already has the full response
(in which case, the byterange filter has enough information to do its
job) or it has no choice (chunking not allowed, and this MUST be a
keepalive connection).  Your statement above is incorrect; moving the
byterange filter to after the C-L filter does not allow it to see the
true content length.  In many cases, it simply allows it to see that we
have removed the content length, which means that the byterange filter
must buffer everything.

> >  The original reason for using this ordering, was that we
> > wanted all byterange requests to have a C-L, which this ordering
> > accomplishes.
> 
> Please explain.  Can you provide a scenario where my patch fails?

Your patch is essentially a no-op.  If it succeeds, it is because the
byterange filter has a bug that is showing up when it has a C-L, but it
doesn't have all of the content.  Fix the bug, and moving the filters
isn't necessary anymore.  If you move the filters, the bug still
remains, it is just hidden a bit better.

Ryan



Mime
View raw message