The confusion results because mod_proxy isn't implemented as a content handler, it's a protocol handler in its own right. Rather than insist on the mod_http <> mod_proxy agreeing to streamline the response, we've put it on every content module author to:
. remove output C-L header if the size is transformed . remove input range headers if the content isn't 1:1 transformed
This is very kludgy and more an example of where mod_http <> mod_proxy didn't quite get it right, and made it a little more difficult for folks who are just trying to transform content bodies.
It would be nice in apache 2.2 to finally clean up this contract, with two simple metadata element to pass through the filter chain:
. this request is unfiltered . this request has a 1:1 filter (stateless) . this request has a arbitrary content transformation
Each filter is the stack could promote the complexity but should never set it to a lower state. This would allow http/proxy modules to negotiate less complex transformations in more efficient ways.
Reading the Byterange thread now, I see what OtherBill's position was. Tossing the C-L and Range metadata from the filters is a definite good thing. They just shouldn't know about that metadata. ++1 there.
But, I'm not convinced that the benefit gained by allowing some byte-range optimization is going to be worth it. As soon as you stick in mod_include and/or mod_deflate, you're going to have the ability to have arbitrary content transformation. Even EBCDIC character conversions is not one-to-one. In fact, I bet the number of filters that do a 1:1 transformation (that aren't logging) is small. So, the number of cases where it isn't arbitrary would be extremely miniscule. Yet, perhaps I'm wrong here... -- justin
