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 19:36:19 GMT
On Tue, 13 Jul 2004, Graham Leggett wrote:

> Nick Kew wrote:
> > 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.
> Remember that in our case there is no such thing as a "caching proxy".

Of course there is!  It's apache with mod_proxy and mod_cache.  Just
as a content-transforming proxy is apache with mod_proxy and one or
more content filter module.

> > Bottom line: this has to be controlled by the server admin.  We offer
> > the options of passthrough, process locally, or ignore ranges.
> I think it's better to avoid adding extra directives, or giving the
> admin the power to override RFC2616. How to handle ranges is described
> fully in the HTTP/1.1 spec, the admin shouldn't really have the option
> to fiddle with it. Just adding more ways to get it wrong.

AFAICS RFC2616 sanctions any of the three behaviours I'm proposing.
Firstly noone is required to support ranges at all.  Secondly the
following passage from #14.35 seems to sum up the other options:

   If a proxy that supports ranges receives a Range request, forwards
   the request to an inbound server, and receives an entire entity in
   reply, it SHOULD only return the requested range to its client. It
   SHOULD store the entire received response in its cache if that is
   consistent with its cache allocation policies.

That's not explicit about whether the Range was forwarded, but neither
AFAICS is anything else in the RFC.

> Any filter that could get it's hands dirty (mod_include springs to mind)
> should just strip the Range header from the request, leaving the byte
> range filter to do the dirty work for it on the full response.

That is dirtying the filter API further.  If filter modules are to
be responsible for that, we should at least provide a higher-level
API for them, ideally in a declarative form.  Maybe something along the
lines of an AP_IS_TRANSFORM flag or flags, that will transparently deal
with Content-Length, Range and Warning headers on behalf of a filter
when it is inserted.

If we can abstract out the common processing required of every
content-transforming filter into a simple magic-API, I'll be happy.

Nick Kew

View raw message