The byte ranges aren't done for the benefit of the httpd itself, but rather a potential multi tier backend supported by mod_proxy or mod_backhand.
Right now if you range request a big file, it will work - but not before the entire big file has been passed from the backend application server to the frontend httpd over the backend network. If you think of files the sizes of CD ISOs (650MB) of DVD ISOs (4GB) this backend transfer is not trivial. Add a download accelerator to the equation (likely on a big file like a CD) and suddenly the entire file is transferred once for each range request, ouch.
There are two use cases here:
1) a proxy that does modify the origin representation 2) a proxy that does not modify the origin representation
The degenerate file serving case you describe is #2 - here the ideal would be to have the byterange request passed to the origin server and let it handle it. However, there's just no way for the proxy to know ahead of time what the filters will do, so without explicit *user* direction, the proxy MUST get the full response and run it through the filters.
Instead, what mod_proxy could do is expose a user directive that says 'no representation transformation allowed' and act accordingly: bypass all filters except for the network filters. This isn't a problem with filters per se: it's a problem with trying to conflate a variety of functionality in one node. To err on the safe side, that directive should default to the 'representation-modifying' case but allow the admin to say 'we will not modify the representation.' That would allow the degenerate case you describe to be resolved in a performance-efficient manner...
Also note that mod_cache suffers from this same problem. -- justin
