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, ther
--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
Justin Erenkrantz wrote:
But, I'm not convinced that the benefit gained by allowing some
byte-range optimization is going to be worth it. As soon as you stick
in mod_include and/or mod_deflate, you're going to have the ability to
have arbitrary content transformation. Even EBCDIC character
co
--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 respon
--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 l
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
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-transformi
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 under
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 overri
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
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
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
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 st
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 tho
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
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 exac
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().
Bein
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
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
>> r
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 th
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 e
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 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
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
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 respons
> 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
> re
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 s
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
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 y
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
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 this.
31 matches
Mail list logo