On 1-Aug-04, at 4:41 PM, Justin Erenkrantz wrote:
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.
In fact, if the filter chain cannot optimise byte ranges,
--On Tuesday, July 13, 2004 11:21 AM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
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
--On Tuesday, July 13, 2004 10:35 AM -0500 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
The confusion results because mod_proxy isn't implemented as a content
handler, it's a protocol handler in its own right. Rather than insist on the
mod_http mod_proxy agreeing to streamline the response,
--On Sunday, August 1, 2004 11:17 PM +0200 Graham Leggett [EMAIL PROTECTED]
wrote:
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
Geoffrey Young wrote:
while I'm all for reducing server overhead (who isn't :) playing these kind
of games with the filter API seems like such a bad idea. what we have now
is a modular design that is simple and works - content handlers generate a
response, while various filters adjust that
On Mon, Jul 12, 2004 at 03:35:12AM +0100, Nick Kew wrote:
This doesn't completely address the issue that this might cause
excessive memory usage; particularly if we have to serve ranges in a
perverse order. I would propose two admin-configurable limits:
(1) Total data buffered in memory by
On Mon, Jul 12, 2004 at 03:49:08PM +0200, Graham Leggett wrote:
I am assuming the current behaviour of the byte range filter would apply
the range to the content without checking first whether this has already
been done. This fix is very straightforward.
As far as I can tell the byterange
Joe Orton wrote:
As far as I can tell the byterange filter should handle all such cases
correctly already: read ap_set_byterange() - it punts on a non-200
r-status or when r-headers_out contains a Content-Range header etc.
Is this side-discussion just theoretical pondering or is there some real
On Tue, Jul 13, 2004 at 12:22:20PM +0200, Graham Leggett wrote:
Joe Orton wrote:
As far as I can tell the byterange filter should handle all such cases
correctly already: read ap_set_byterange() - it punts on a non-200
r-status or when r-headers_out contains a Content-Range header etc.
Is
Joe Orton wrote:
Yes, that's exactly what it's supposed to do already. I haven't checked
that it works via the proxy but it certainly does for other cases.
Ok, then most of the problem is solved :)
The full 650MB CD ISO is then transferred from the backend to the
frontend, which then pulls out
Graham Leggett wrote:
Geoffrey Young wrote:
while I'm all for reducing server overhead (who isn't :) playing these
kind
of games with the filter API seems like such a bad idea. what we have
now
is a modular design that is simple and works - content handlers
generate a
response, while
On Tue, 13 Jul 2004, Joe Orton wrote:
On Mon, Jul 12, 2004 at 03:35:12AM +0100, Nick Kew wrote:
This doesn't completely address the issue that this might cause
excessive memory usage; particularly if we have to serve ranges in a
perverse order. I would propose two admin-configurable
On Tue, 13 Jul 2004, Joe Orton wrote:
I'm beginning to think the only sane way to fix the byterange filter is
to have it do nothing if it isn't passed a complete EOS-terminated
brigade with a predetermined length, i.e. no morphing CGI buckets which
will eat all your RAM when they get -read().
Geoffrey Young wrote:
please take the rest of this as just a friendly discussion - I don't want it
to turn into some kind of bickering match, since that's definitely not what
I have in mind :)
Cool no problem - it's quite a complex thing this, and I was struggling
trying to make it clear what
At 05:22 AM 7/13/2004, Graham Leggett wrote:
The problem arises when large data sizes (say a 650MB CD ISO) are stored in a
multi-tier webserver architecture (mod_proxy in front of a backend, for example), and
somebody comes along and tries to download it using a download accelerator, or they
William A. Rowe, Jr. wrote:
The solution to this problem is *not* to become tightly coupled with the
placement of filters, directly handling file streams, etc.
The clean solution is a new forward-space semantic for the filter or
brigade, which would allow you to skip n bytes. This would allow
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
Graham Leggett wrote:
Geoffrey Young wrote:
please take the rest of this as just a friendly discussion - I don't
want it
to turn into some kind of bickering match, since that's definitely not
what
I have in mind :)
Cool no problem - it's quite a complex thing this, and I was
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
At 08:44 AM 7/13/2004, Graham Leggett wrote:
Geoffrey Young wrote:
ok, that isn't the idea I had about output filters at all. my own concept
of how this all worked (or should work) is that content handlers are
supposed to just generate content. specifically, they should not care at
all about
At 10:57 AM 7/13/2004, Graham Leggett wrote:
Nick Kew wrote:
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
William A. Rowe, Jr. wrote:
I don't like where this conversation is heading at all. You are suggesting that
every filter needs to become progressively more aware of the http module
characteristics, but that's what we were moving away from in apache 2.0.
Ok, this is exactly how Geoffrey Young
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,
On Tue, 13 Jul 2004, William A. Rowe, Jr. wrote:
It would be nice in apache 2.2 to finally clean up this contract, with two
simple metadata element to pass through the filter chain:
. this request is unfiltered
. this request has a 1:1 filter (stateless)
. this request has a arbitrary
Ian Holsman wrote:
ok, now before I start this let me say one thing, this is not for *ALL*
requests, it will only work for ones which don't have content-length
modifiable filters (like gzip) applied to the request, and it would be
left to the webserver admin to figure out what they were, and if
On Mon, 12 Jul 2004, Graham Leggett wrote:
at the moment when a byterange request goes to a dynamic module, the
dynamic module can not use any tricks to only serve the bytes requested,
it *HAS* to serve the entire content up as buckets.
In theory, if mod_proxy (for example) gets a byte
Nick Kew wrote:
That will not always be practicable. mod_proxy should be configurable
to pass byteranges headers straight through to the backend or strip them
and assume the proxy will handle the ranges.
Byte ranges are a part of HTTP/1.1, and mod_proxy claims to be an
HTTP/1.1 proxy. mod_proxy
Which in turn means that every filter, now blissfully unaware of ranges,
is forced to generate a full response for each byterange request. In the
case of a downloaded ISO (for example), this means a significant amount
of data (many hundreds of MB) is being processed by filters on each
ok, now before I start this let me say one thing, this is not for *ALL*
requests, it will only work for ones which don't have content-length
modifiable filters (like gzip) applied to the request, and it would be
left to the webserver admin to figure out what they were, and if you
could use
On Mon, 12 Jul 2004, Ian Holsman wrote:
ok, now before I start this let me say one thing, this is not for *ALL*
requests, it will only work for ones which don't have content-length
modifiable filters (like gzip) applied to the request, and it would be
left to the webserver admin to figure out
30 matches
Mail list logo
