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. > 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 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? Greg
