Is there a way that I can peek at the request from within a Connection
filter? In other words, I need to examine the actual HTTP request in order
to affect something in another Connection filter. A constraint is that I
cannot modify this other Connection filter.
It seems I am in a somewhat
On 09/13/2010 01:16 AM, minf...@apache.org wrote:
Author: minfrin
Date: Sun Sep 12 23:16:49 2010
New Revision: 996395
URL: http://svn.apache.org/viewvc?rev=996395view=rev
Log:
mod_cache: Change the signature of the store_body() provider function
within the mod_cache provider interface
- Sergio Junqueira sjjrb...@yahoo.com wrote:
Do you need the first entry to determine which request may have
caused httpd to crash or is there a different reason?
Mod_log_forensics writes the log record as soon as it is received.
Mod_log_config writes the log record after the
On 09/13/2010 01:29 AM, Graham Leggett wrote:
Hi all,
The CacheMinFileSize and CacheMaxFileSize directives in mod_disk_cache
are currently set per server, which seems to be historical from the time
before mod_cache could be added as a normal handler / specifically
placed filter. This
Graham Leggett wrote:
On 06 Sep 2010, at 11:00 PM, Paul Querna wrote:
Isn't this problem an artifact of how all bucket brigades work, and is
present in all output filter chains?
An output filter might be called multiple times, but a single bucket
can still contain a 4gb chunk easily.
It
Have you already exhausted other methods such as mod_whatkilledus?
Not yet. I didn't know about it. But my main concern now is to account for all
incoming requests, no matter if they fail. I need to identify every request
received by Apache, when it was received, when and if a response was
On 13 Sep 2010, at 1:14 PM, Paul Fee wrote:
Retrieving bodies from the cache has a similar scalability issue. The
CACHE_OUT filter makes a single call to the provider's
recall_body(). The
entire body must be placed in a single brigade which is sent along the
filter chain with a single
On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote:
It is not a problem for mod_disk_cache as you say, but
I guess he meant for 3rd party providers that could only deliver
the cached responses via heap buckets.
The cache provider itself puts the bucket in the brigade, and has the
-Original Message-
From: Graham Leggett
Sent: Montag, 13. September 2010 16:35
To: dev@httpd.apache.org
Subject: Re: mod_cache: store_body() bites off more than it can chew
On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote:
It is not a problem for mod_disk_cache as
Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Graham Leggett
Sent: Montag, 13. September 2010 16:35
To: dev@httpd.apache.org
Subject: Re: mod_cache: store_body() bites off more than it can chew
On 13 Sep 2010, at 4:18 PM, Plüm, Rüdiger, VF-Group wrote:
It is not
On 13 Sep 2010, at 8:47 AM, Ruediger Pluem wrote:
Can't this lead to a situation where buckets that follow an EOS
bucket (the only ones
I can think of are Metabuckets) get swallowed forever by
mod_disk_cache?
These possible Metabuckets will be swallowed and added to dobj-bb,
but never put
On 9/13/2010 6:27 PM, Jeff Trawick wrote:
I've seen you and somebody else say that, so I'll stop. At the same time I
will point out
that
Coulda been me before (on a different patch issue)
* Sometimes people without commit access ask for something to be backported,
possibly even
with a
12 matches
Mail list logo
