flood STATUS: -*-text-*-
Last modified at [$Date: 2003/07/01 20:55:12 $]
Release:
1.0: Released July 23, 2002
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
milestone-02: Tagged August 13,
httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
Geoffrey Young wrote:
But it's quite possible that argument could be readonly while not a
string, a simple example is a return value of a function:
% perl -le 'a(b(), b); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
sub b { 5 }'
Modification of a read-only value attempted at -e line 1.
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
But it's quite possible that argument could be readonly while not a
string, a simple example is a return value of a function:
% perl -le 'a(b(), b); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
sub b { 5 }'
Modification of a
Geoffrey Young wrote:
just add a line like, remove after Sep 15th or so. and may be take it into
if ($deprecated) { ...}
so it's easy to remove the whole branch at once without thinking too much.
the logic was already wrapped in an if block, so I just made a note that we
want it removed by mid
On Wed, Jun 09, 2004 at 05:23:38PM -0400, Allan Edwards wrote:
Running ProxyPass with mod_deflate results in
an extraneous 20 bytes being tacked onto 304
responses from the backend.
The problem is that mod_deflate doesn't handle
the zero byte body, adds the gzip header and
tries to
On Wed, 9 Jun 2004, Allan Edwards wrote:
Running ProxyPass with mod_deflate results in
an extraneous 20 bytes being tacked onto 304
responses from the backend.
The problem is that mod_deflate doesn't handle
the zero byte body, adds the gzip header and
tries to compress 0 bytes.
This
Brad Nicholes wrote:
I guess that is a possibility but I still don't understand what the
problem is with using calloc() and free() for the ldap caching code.
This seems to be a common thing to do when global memory needs to be
allocated and deallocated constantly. To avoid having the memory
A security issue has been reported in mod_proxy. See
http://www.guninski.com/modproxy1.html
The flaw affects Apache httpd 1.3.25 to 1.3.31 that have mod_proxy enabled
and configured. Apache httpd 2.0 is unaffected.
The security issue is a buffer overflow which can be triggered by getting
I agree that the LDAP code needs to do more error checking and
between the work that you did, along with the holes that I plugged
previously and the shared memory fixes that Mathieu Estrade did, I think
the code is much more robust than it has ever been. Many of our NetWare
customers use
Joe Orton wrote:
Wouldn't it be simpler to just check for a brigade containing just EOS
and do nothing for that case in the first place?
Yes I had considered that. The initial patch covered some pathological
cases but after having looked over the code some more I think the simpler
more efficient
Brad Nicholes wrote:
At least on NetWare, switching to pools would make the code much
more complex. Rather than simply calling calloc and free in the same
way that we are calling apr_rmm_calloc() and apr_rmm_free(), we would
have to implement essentially the same model using pools and
I have considered using a pool per entry in other caching code that I
have written just so that I could have much finer control over
allocating and freeing the memory. But in the end what it really comes
down to is malloc and free and if that is what you really want, then why
not just use
On Wed, 9 Jun 2004, Jim Jagielski wrote:
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
I guess what we are agreeing on here is that the logic that sets
keepalive
to 0 is faulty and that is probably where the real fix lies.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
Brad Nicholes wrote:
Do we even know that there is a problem with this code? I haven't seen
any memory leaks so far. I would hate to go to all of the work to
redesign and rewrite the ldap_cache manager for little to no gain.
It does not seem to handle the we ran out of memory while trying to add
It appears to me that if it doesn't handle low memory situations or
it is giving false positives, those are separate issues from pools vs.
calloc/free. I still think we need to implement some better monitoring
or logging code in the cache_mgr and enhance the cache-status pages so
that we can
Back in February I submitted a patch to use the httpready accept filter,
and it was committed to 2.1:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/listen.c?r1=1.95r2=1.96
Pretty simple change, is there any chance someone can start a vote on
getting it backported to the 2.0 Branch?
Thanks,
In fact, I don't think that these are shared locks at all
#define LDAP_CACHE_LOCK_CREATE(p) \
if (!st-util_ldap_cache_lock)
apr_thread_rwlock_create(st-util_ldap_cache_lock, st-pool)
which means that in the shared memory cache, it is highly likely that
multiple processes could be altering
On Thu, 10 Jun 2004, Paul Querna wrote:
Pretty simple change, is there any chance someone can start a vote on
getting it backported to the 2.0 Branch?
done.
i'll review it myself sometime tonight.
Cliff Woolley wrote:
On Wed, 9 Jun 2004, Geoffrey Young wrote:
I wanted to ping everyone about an idea I've been throwing around for a few
months now. I'd like the ability to shuffle the declared hook ordering
around, most likely during the post-config phase.
There was some discussion
20 matches
Mail list logo
