> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On


> I can get this to seg fault on my ThinkPad pretty easily, running a
> byterange
> request that looks like what I posted.  This happens when the
byterange
> filter
> thinks it should generate an error bucket with
HTTP_RANGE_NOT_SATISFIABLE.
> But
> sometimes it generates these invalidly.
> 
> The byterange filter appears to be in the wrong place in the filter
chain.
> It
> is above the C_L filter, which creates a major problem.  It can't tell
> what the
> full content length is for the entire request, so it can't do its job
as
> far as
> determining if a Range: header applies.  Yeah, if you serve unparsed
> static
> pages only, it happens to work.  But try it with mod_include or
another
> filter
> which can expand or shrink the output and all bets are off.

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.  Moving the filters around is the wrong solution
IMO, because it doesn't solve the problem that the filter is not working
correctly.  The original reason for using this ordering, was that we
wanted all byterange requests to have a C-L, which this ordering
accomplishes.

Ryan



Reply via email to