httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Sun, 01 Aug 2004 21:41:17 GMT
--On Sunday, August 1, 2004 11:17 PM +0200 Graham Leggett <> 

> 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

View raw message