On Fri, Apr 22, 2005 at 04:42:04PM -0500, Rici Lake wrote:
On 22-Apr-05, at 9:32 AM, Joe Orton wrote:
The issue here is really which party can *destroy* a brigade, right?
Or perhaps which party *must* destroy a brigade. This is much less of
an issue if neither party creates a new
On Mon, 25 Apr 2005, Joe Orton wrote:
1. update the util_filter.h documentation
2. add some APR_BUCKET_DEBUG code to abort() when brigades are used
after being destroyed
3. adjust all filters to work with this model
4. switch to allocate brigades out of the bucket allocator
Didn't we try #4
On 25-Apr-05, at 10:15 AM, Cliff Woolley wrote:
4. switch to allocate brigades out of the bucket allocator
Didn't we try #4 before and something bad happened? I don't remember
what that would have been, I just feel certain #4 has been previously
discussed at least.
I think the something bad would
On 25-Apr-05, at 8:29 AM, Joe Orton wrote:
I think it's fine to leave the *contents* of the brigade as undefined
after a call to ap_pass_brigade. (that's essentially the case now
since
it's not explicitly defined to be empty: I don't know of any
particular bugs which have been caused by this?)
Hello,
Just curious, is there any reason someone on this list would
intentionally attach a file with a .scr ending? Periodically I get the
ezmlm program emailing me and complaining that sometimes my address
bounces messages back. I've looked and it is because they contain files
with the .scr
.scr files are usually windows screensaver files (exe files with another
extension).
Most probably they are virus/worms/trojan , etc.
If they are bounced to you, as if you were sending them, it is because
someone with windows (outlook probably) has you on the address book, and
his computer is
On Mon, 25 Apr 2005, Nathanael Noblet wrote:
Just curious, is there any reason someone on this list would
intentionally attach a file with a .scr ending? Periodically I get the
ezmlm program emailing me and complaining that sometimes my address
bounces messages back. I've looked and it
On Mon, Apr 25, 2005 at 11:15:02AM -0400, Cliff Woolley wrote:
On Mon, 25 Apr 2005, Joe Orton wrote:
1. update the util_filter.h documentation
2. add some APR_BUCKET_DEBUG code to abort() when brigades are used
after being destroyed
3. adjust all filters to work with this model
4.
On Mon, Apr 25, 2005 at 10:44:39AM -0500, Rici Lake wrote:
Allocating the brigade out of the bucket allocator but continuing to
register the cleanup with a pool (say, the request pool if that were
appropriate) might work but it would be fragile.
Fragile, why? That's exactly the right
On Mon, Apr 25, 2005 at 05:21:42PM -, Jim Jagielski wrote:
...
--- httpd/httpd/branches/2.0.x/STATUS (original)
+++ httpd/httpd/branches/2.0.x/STATUS Mon Apr 25 10:21:40 2005
@@ -95,6 +95,11 @@
identify exactly what the proposed changes are! ]
[ please append new backports at the
On 25-Apr-05, at 12:05 PM, Joe Orton wrote:
Fragile, why? That's exactly the right approach as far as I can see.
Because the pool might have a lifetime *longer than* the bucket
allocator. OK, that's not likely in the current architecture, so it
would be a concern only for non-httpd
Regardless of any other changes to the brigade API, this seems to me to
be a good idea:
Index: util_filter.c
===
--- util_filter.c (revision 158730)
+++ util_filter.c (working copy)
@@ -500,6 +500,7 @@
Rici Lake wrote:
Regardless of any other changes to the brigade API, this seems to me to
be a good idea:
+1. I agree, while the discussion on other 'rules' for brigades is
good, I think this patch should be applied regardless.
It seems all of the other discussion has revolved around the
Joe Orton wrote:
On Mon, Apr 25, 2005 at 05:21:42PM -, Jim Jagielski wrote:
...
--- httpd/httpd/branches/2.0.x/STATUS (original)
+++ httpd/httpd/branches/2.0.x/STATUS Mon Apr 25 10:21:40 2005
@@ -95,6 +95,11 @@
identify exactly what the proposed changes are! ]
[ please
Patch to use a single temporary brigade instead of creating a new one
on each invocation:
(also does a little code reuse)
Index: mod_ext_filter.c
===
--- mod_ext_filter.c(revision 158730)
+++ mod_ext_filter.c(working copy)
I didn't reindent so that the patch would be clearer.
Index: mod_include.c
===
--- mod_include.c (revision 158730)
+++ mod_include.c (working copy)
@@ -3542,7 +3542,6 @@
intern-end_seq_len =
--On Monday, April 25, 2005 12:47 PM -0500 Rici Lake [EMAIL PROTECTED]
wrote:
Regardless of any other changes to the brigade API, this seems to me to
be a good idea:
Index: util_filter.c
===
--- util_filter.c (revision 158730)
On 25-Apr-05, at 1:30 PM, Justin Erenkrantz wrote:
--On Monday, April 25, 2005 12:47 PM -0500 Rici Lake
[EMAIL PROTECTED] wrote:
Regardless of any other changes to the brigade API, this seems to me
to
be a good idea:
Index: util_filter.c
--On Monday, April 25, 2005 3:06 PM -0500 Rici Lake [EMAIL PROTECTED]
wrote:
Can you quantify that large overhead? In the case of a 'compliant'
filter, it consists of:
With Joe's suggestion for 'creator must destroy', this step is wholly
unnecessary and only overcomplicates things. -- justin
I'm seeing changed behavior between 2.1 and previous releases, under
the following example config:
VirtualHost *:8080
ProxyRequests on
ProxyRemote * http://proxy:8080
ProxyBlock blocked
/VirtualHost
In a request for http://requested/ I can see that mod_proxy compares
the addresses for blocked
On 25-Apr-05, at 3:36 PM, Justin Erenkrantz wrote:
--On Monday, April 25, 2005 3:06 PM -0500 Rici Lake
[EMAIL PROTECTED] wrote:
Can you quantify that large overhead? In the case of a 'compliant'
filter, it consists of:
With Joe's suggestion for 'creator must destroy', this step is wholly
Index: mod_include.c
===
--- mod_include.c (revision 158730)
+++ mod_include.c (working copy)
@@ -3060,7 +3060,7 @@
struct ssi_internal_ctx *intern = ctx-intern;
request_rec *r = f-r;
apr_bucket *b =
On Mon, Apr 25, 2005 at 03:58:59PM -0500, Rici Lake wrote:
If we accept that the contents of a brigade are undefined when
ap_pass_brigade returns, the caller has three options:
-- call cleanup and reuse the brigade
-- call destroy (which will first call cleanup)
-- drop it on the floor and
* Rici Lake wrote:
+1 in general, but ...
Index: mod_include.h
===
--- mod_include.h (revision 158730)
+++ mod_include.h (working copy)
@@ -85,6 +85,9 @@
/* currently configured time format */
const
* Rici Lake wrote:
I didn't reindent so that the patch would be clearer.
FWIW, I think, it's ok. But not tested...
nd
--
Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...
[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du
Why do pool buckets do an automatic setaside? Should they?
No other bucket type does this; consequently, if you want to hold on to
a bucket beyond the scope of the call in which you received the
brigade, you must explicitly call bucket_setaside.
Without examining the bucket type, a practice
Joe Orton [EMAIL PROTECTED] writes:
But in the latter two cases, adding a apr_brigade_cleanup() call to
ap_pass_brigade() is completely redundant. To me, you need to make the
argument that the former case is so prevalent that it's worth an
additional API guarantee, and the additional (small)
On 25-Apr-05, at 4:27 PM, André Malo wrote:
* Rici Lake wrote:
+1 in general, but ...
...put it into the internal structure, please. That's I've created it
for
(binary compat and only making stuff public what matters the public).
nd
--
Muschelflucht-Zusatzeinrichtung.
Shell-Escape ist ja noch
--On Monday, April 25, 2005 4:47 PM -0500 Rici Lake [EMAIL PROTECTED]
wrote:
explicit cleanup, while we continue thrashing out that issue. (nd -- do
you have a test suite, by any chance?)
httpd-test's has a bunch of tests for mod_include. -- justin
On Mon, 25 Apr 2005, Rici Lake wrote:
Why do pool buckets do an automatic setaside? Should they?
They set themselves aside when the pool in which their data was allocated
is in the process of being destroyed. This is necessary because no other
bucket type has a similarly unpredictable
On 25-Apr-05, at 5:04 PM, Cliff Woolley wrote:
Why do pool buckets do an automatic setaside? Should they?
They set themselves aside when the pool in which their data was
allocated
is in the process of being destroyed. This is necessary because no
other
bucket type has a similarly unpredictable
On Mon, 25 Apr 2005, Rici Lake wrote:
Surely this is equally true of any pool-related resource. For example,
a file which has been opened and has a pool cleanup registered would
have exactly the same lifetime as a pool-allocated string.
Hmm... for some reason I thought file buckets morphed
Look at:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl/ssl_expr.c
It has two globals:
ssl_expr_info_type ssl_expr_info;
char *ssl_expr_error;
Which are used inside the ssl_expr_comp(), which is called from
ssl_cmd_SSLRequire().
SSLRequire can be put in an .htaccess
On 25-Apr-05, at 4:26 PM, Joe Orton wrote:
On Mon, Apr 25, 2005 at 03:58:59PM -0500, Rici Lake wrote:
If we accept that the contents of a brigade are undefined when
ap_pass_brigade returns, the caller has three options:
-- call cleanup and reuse the brigade
-- call destroy (which will first call
At 05:58 PM 4/25/2005, Paul Querna wrote:
Look at:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl/ssl_expr.c
It has two globals:
ssl_expr_info_type ssl_expr_info;
char *ssl_expr_error;
Wouldn't this mean in a threaded MPM, that two threads could easily be
parsing
Justin Erenkrantz wrote:
--On Monday, April 25, 2005 12:47 PM -0500 Rici Lake [EMAIL PROTECTED]
wrote:
-return next-frec-filter_func.out_func(next, bb);
+result = next-frec-filter_func.out_func(next, bb);
+apr_brigade_cleanup(bb);
}
-return
--On Monday, April 25, 2005 9:34 PM -0700 Paul Querna [EMAIL PROTECTED]
wrote:
Plus, I hear those new dual core opterons are really nice. I would
rather have a better and cleaner API, than save a few CPU cycles here.
The posted patch does nothing to make the brigades or filter a cleaner API.
37 matches
Mail list logo
