On Tue, Sep 10, 2002 at 12:08:42AM -0700, Aaron Bannert wrote:
> On Mon, Sep 09, 2002 at 11:36:11PM -0700, Justin Erenkrantz wrote:
> > But, I still think producing unobfuscated md5 hashes is a useful
> > option, so I'll leave this commit in. -- justin
>
> I'm totally out of my league here, but
On Mon, Sep 09, 2002 at 11:21:04PM -0700, Greg Stein wrote:
> On Mon, Sep 09, 2002 at 01:33:25PM -0700, Jon Travis wrote:
> > Ok, since I'm not seeing any activity towards getting this
> > integrated, I'd like to set a deadline. This would help
> > me out, since it gives direction as to where th
On Mon, Sep 09, 2002 at 11:36:11PM -0700, Justin Erenkrantz wrote:
> But, I still think producing unobfuscated md5 hashes is a useful
> option, so I'll leave this commit in. -- justin
I'm totally out of my league here, but is this different than say
md5sum? (It still might make sense to keep it,
On Tue, Sep 10, 2002 at 08:51:09AM +0200, Graham Leggett wrote:
> I don't see the auth_ldap stuff included - is it on the cards to be part
> of the rewrite?
Yeah, ldap is kind of on the radar screen, but it can keep using the
same external auth API (none of the external APIs changed - just how
t
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 10 September 2002 01:27
> Sander (& Co)
>
>with .40, we backed out the apr-iconv due to it's not-ready state,
> with the attached patch.
>
>I've been intending to get the openssl/iconv/zlib library linkage stubs
> done for
[EMAIL PROTECTED] wrote:
> Stage #1 of the aaa rewrite - refactoring modules.
>
> All modules are reorganized under the following scheme:
> - mod_auth_*: Front-end (basic, digest)
> - mod_authn_*: Authentication (anon, dbm, default, file)
> - mod_authz_*: Authorization (dbm, defa
On Tue, Sep 10, 2002 at 03:00:51AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz2002/09/09 20:00:50
>
> Modified:.CHANGES
>support htpasswd.c
> Log:
> Add ability to htpasswd (via -5) to produce non-obfuscated MD5 hashes.
>
> mod_auth_digest's passwords
In preparation for the new auth changes that have been discussed
on this list, I have created a tag that marks as near as possible a
point in time before any of the new auth changes were implemented,
called AGB_BEFORE_AAA_CHANGES. I'm sure this will come in handy,
even for you skeptics. :)
-aaron
Sander (& Co)
with .40, we backed out the apr-iconv due to it's not-ready state,
with the attached patch.
I've been intending to get the openssl/iconv/zlib library linkage stubs
done for Win32, but my time's been rather short. I should be able
to attack it late this week or early next wee
What's the current status? Have we tagged for 2.0.41 yet or no? Will this be
happening today/tonight/early tomorrow morning? (IE, I'm installing
subversion and I'd PREFER to grab 2.0.41 and not head.)
On Saturday 07 September 2002 11:12 am, Sander Striker wrote:
> Hi,
>
> I tagged the tree t
Sander Striker wrote:
>
> Hi,
>
> I tagged the tree today as STRIKER_2_0_41_PRE1. I'll do some
> testing this weekend myself and will retag for release after
> I get some positive feedback on this tag.
>
> Greg, could you bump daedalus to this tag next week to see how
> it holds?
Sure. I was
David Hill wrote:
>For Tru64, the compiler defines two things, __alpha and __osf__ , either can
>be used, the __osf__ tends to be used more.
>So:
>
>#if HAVE_ALLOCA && defined(__osf__)
>
Thanks. I'll commit in a minute.
Brian
I recently ran into an issue with non-ASCII user names in LDAP-based authentication
-- both via the Apache 1.3.x auth_ldap module from www.rudedog.org and with
the httpd-ldap sub-project for Apache 2.0.x.
This issue is rather nicely documented in:
http://www.rudedog.org/pipermail/auth_ldap/200
On Fri, Sep 06, 2002 at 02:44:23PM -0700, Sander Temme wrote:
> All,
>
> The following patch allows MacOSX/Darwin to find the SSL library. With this
> patch, the current CVS HEAD of httpd-2.0 compiles with mod_ssl enabled and
> passes all ssl tests in the perl-framework (except for ssl/proxy sinc
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 09, 2002 3:02 PM
Subject: Re: alloca() issue on tru64
> Dave Hill wrote:
>
> >Hi all,
> > While digging into that mysterious hang of Apache 2 on Tru64,
> >I found that it seemed t
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
> Sent: 09 September 2002 22:42
> On Mon, 9 Sep 2002, Brad Nicholes wrote:
>
> > Has anybody else noticed a memory leak when requesting pages less
> > than 8k? If I repeatedly request pages less than 8k I have noticed that
> > apr_bucket_all
It's possible that if it goes elsewhere that it would be under a
different license. That's of course contingent on the decision
from the ASF.
-- Jon
On Mon, Sep 09, 2002 at 01:50:18PM -0700, Scott Hess wrote:
> I'm not sure I understand what your goal is, here. The discussion seems
> to be
I'm not sure I understand what your goal is, here. The discussion seems
to be +1 for including your parser somewhere in some Apache project in the
future, there's just no clear concensus on where. Is there any reason you
can't just release your project under the ASF license and be done with it?
On Mon, 9 Sep 2002, Brad Nicholes wrote:
> Has anybody else noticed a memory leak when requesting pages less
> than 8k? If I repeatedly request pages less than 8k I have noticed that
> apr_bucket_alloc() calls allocator_alloc() which seems to continuously
> malloc() memory rather than findi
Has anybody else noticed a memory leak when requesting pages less
than 8k? If I repeatedly request pages less than 8k I have noticed
that
apr_bucket_alloc() calls allocator_alloc() which seems to continuously
malloc() memory rather than finding it in the free list. The reason
why
is because
Ok, since I'm not seeing any activity towards getting this
integrated, I'd like to set a deadline. This would help
me out, since it gives direction as to where the project
can go, as well as the ASF since political discussion shouldn't
weigh down the process. It will just save us all a lot of
t
On Mon, Sep 09, 2002 at 12:02:02PM -0700, Brian Pane wrote:
> Dave Hill wrote:
>
> >Hi all,
> > While digging into that mysterious hang of Apache 2 on Tru64,
> >I found that it seemed to be hanging under apr_poll in alloca()
> >While I found that the problem seems to go away when not using a
Dave Hill wrote:
>Hi all,
> While digging into that mysterious hang of Apache 2 on Tru64,
>I found that it seemed to be hanging under apr_poll in alloca()
>While I found that the problem seems to go away when not using a
>prerelease version of the OS, it did bring something to my attention
Hi all,
While digging into that mysterious hang of Apache 2 on Tru64,
I found that it seemed to be hanging under apr_poll in alloca()
While I found that the problem seems to go away when not using a
prerelease version of the OS, it did bring something to my attention.
According to "Thos
thanks for the response, much appreciated.
yeah, for the +s stuff i've just run 'chatr +s enable' over the entire
build output (well the bin & lib hieararchy anyway). it's cheap and fast ;)
cheers,
andy
Jeff Trawick wrote:
> Andy Cutright <[EMAIL PROTECTED]> writes:
>
>
>>hi,
>>
>>so could
Time for another ping. It's been 2 weeks. Any word?
-- Jon
On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote:
> Hi all...
> Jon Travis here...
>
> Covalent has written a pretty keen HTML parser (called el-kabong)
> which we'd like to offer to the ASF for inclusion in APR-util (or
>
Hi David.
have you looked at Flood ???
I would suggest you take a look at that first, as it is 100 times
better than ab.
http://httpd.apache.org/test/flood/
I know justin & aaron did a presentation about this.. they may be kind
enough to mail you a copy/link
Regards
Ian
David N. Welton wrote:
Ben Hyde wrote:
> Ian Holsman wrote:
> > APR now has version management.
> > is it time to stop just tagging the HEAD of the apr/apr-util trees
>
> +1
>
> This would also change way an httpd 2.0 developer develops, yes?
>
> - ben
>
yes, it could.
It would encourage non-apr developers of ht
[EMAIL PROTECTED] wrote:
On Tue, Sep 03, 2002 at 09:51:20AM -0500, Jess M. Holle wrote:
It would be nicest of all to have builds of each version of the core for
each platform -- and pluggable binaries of all the extra modules for
each version/platform as well.
Eergh.. this s
+1.
Ian Holsman wrote:
>
> APR now has version management.
> is it time to stop just tagging the HEAD of the apr/apr-util trees
> when we make a release and just use the offically released ones?
> ie.. we would bundle apr 0.9.1 with httpd 2.0.41,
> and possibly further on, not bundle apr in the
Ian Holsman wrote:
> APR now has version management.
> is it time to stop just tagging the HEAD of the apr/apr-util trees
+1
This would also change way an httpd 2.0 developer develops, yes?
- ben
[ 3rd time's the charm for this posting? ]
[ Please CC replies to me. ]
I have been hacking at the Apache Benchmark source code, and I am
starting to think that it needs an overhaul, and some extending.
One of the big things that I would like to see would be to library-ize
it, in order to brea
Andy Cutright <[EMAIL PROTECTED]> writes:
> hi,
>
> so could you possibly speak those unspeakable hacks you've made to
> apache to run c++ modules on hp? we're trying to get a c++ module
> linked into 2.0.39. any help would be appreciated. we can take this
> particular aspect of the discussion o
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> Doesn't an option --c-plus-plus make more sense than a platform
> specific link foo option? Shouldn't we just extend libtool to deal with
> the platform specifics, g++ or whatnot, depending on what's required
> to support stl and other specifi
34 matches
Mail list logo
