I changed it to bugpm.pm (and changed the package name) and it worked fine.
Actually, changing it to bug_tm.pm works. I had forgotten to change the
package name when I retested :(. So hyphens in response tests are a bad
thing?
the limitation here is that perl package namespaces cannot
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
thanx!
i wanna write a cache library and come up with 2 different techniques to
allocate cache memory
1) use calloc free for each node
2)create a subpool in pconf for each node
i did some experiment with both.
#define LOOP_SIZE 1#define MEM_SIZE
400
long iCounter;char *ptr =
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
Here's some of the the gprof output from Oprofile:
% cumulative self self total
time samples samplescalls T1/call T1/call name
7.27 154306.00 154306.00 core_input_filter
5.85 278523.00 124217.00
We have already removed your email address from our database. Thank you and have a
wonderful day.
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
At 06:55 AM 7/13/2004, Sadaf Alvi wrote:
i wanna write a cache library and come up with 2 different techniques to allocate
cache memory
1) use calloc free for each node
2) create a subpool in pconf for each node
What your test fails to convey is that alloc and free of one pool is quite
likely
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
The segment on the new filter was great.
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
26 matches
Mail list logo
