Body/content generation or transformation should not be contending with these issues you raised above. It's not unreasonable to expect some metadata to pass through or be transformed (such as a content length, which some filter can tweak or discard altogether.) But it is getting very obscure to expect them to contend with byteranges. What's next?
Agreed.
That's why I proposed a skip-forward semantic to support byte ranges. It's far abstracted from http, is an optional feature (skip if you can, or read if your filter must in order to transform) and trivial to implement. And it's typical of bytestream APIs.
I don't see how a skip feature would work in a push model API like our output filters - perhaps in a pull-model (like input). But, there are so many other problems with the pull model that I think it's not worth the gain of a skip feature. -- justin
