httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 15:38:47 GMT
On Tue, 13 Jul 2004, Graham Leggett wrote:

> But in the case of mod_proxy, mod_jk, etc it is quite valid and very
> desirable for a range request to be passed all the way to the backend,
> in the hope that the backend sends just that range back to mod_proxy,
> which in turn sends it up a filter stack that isn't going to fall over
> because it received a 206 Partial Content response.

Indeed.  In a straight-through proxy that's right.

But in the case of a cacheing proxy, it may be better for it to retrieve
the entire document and manage byteranges locally.  And in the case of
a content-transforming proxy, the filters may need the entire content to
function at all.

Bottom line: this has to be controlled by the server admin.  We offer
the options of passthrough, process locally, or ignore ranges.

> The above is still true - there is (and should be) very little for the
> content handler to worry about when it comes to HTTP compliance, and
> content handlers should have the option to just generate content, as
> they do now.

Agreed.  That applies both to content handlers and content filters.

> The problem though is not with the content handlers but with the filters
>   - filters must not make the assumption that all content handlers only
> serve content and not HTTP headers. When a content handler decides that
> it wants to handle more of the HTTP spec so as to improve performance,
> it should be free to do so, and should not be stopped from doing so due
> to limitations in the output filters.

Indeed, historically (possibly still) content length has been a problem
for filters.  Simply removing the header may not be sufficient if the
content-length filter reinserts it erroneously.  Ranges are more

Basically a proxy or other content generator that takes care of
byteranges itself is going to be incompatible with certain output
filters.  That has to be documented, and there has to be an easy
way for filters to detect when they're not wanted, or for Apache
to mark them inapplicable and refuse to run them at all.
A situation where filters have to get their hands dirty with
partial responses would be a serious problem.

> In other words if mod_proxy is taught how to pass Range requests to the
> backend server, the output filter stack should not stop proxy from doing
> so by removing Range headers unless it is absolutely necessary.

Indeed.  So in httpd.conf we have options for the proxy to pass range
requests through or not.

Nick Kew

View raw message