> Hmm, well all the other test apps are using it...
>
> The general rule I'm moving to is that the "output" all goes to stdout,
> error messages to stderr. So if we have
>
> testing foo
>
> The OK or Failed are both printed on stdout as part of the "output" and the
> error message as to why it fa
> On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > This is the crux of the issue methinks. We don't yet have a module that
> > would allow us to even get close to replacing pools. We need a lot of
> > things from it and Sander and I have had some good early
> discussions about
> >
On Thu, Jun 07, 2001 at 12:30:17AM +0100, David Reid wrote:
> Hmm, well all the other test apps are using it...
Doesn't mean they are right. =)
> The general rule I'm moving to is that the "output" all goes to stdout,
> error messages to stderr. So if we have
>
> testing foo
>
> The OK or Fai
On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> This is the crux of the issue methinks. We don't yet have a module that
> would allow us to even get close to replacing pools. We need a lot of
> things from it and Sander and I have had some good early discussions about
> how it could
Hmm, well all the other test apps are using it...
The general rule I'm moving to is that the "output" all goes to stdout,
error messages to stderr. So if we have
testing foo
The OK or Failed are both printed on stdout as part of the "output" and the
error message as to why it failed goes to std
On Wed, 6 Jun 2001, Ian Holsman wrote:
> maybe you could take a bit at a time
> for example.. modify the pool code so that it has a 'sms' memory pointer
> in the structure, on init/destroy you also clean it up ..
> then you could takle parts of the apr, for example strings
> replacing the 'standar
Hi Sander,
I have an issue with installing open-ssl on machines.
from their home page:
This software package uses strong cryptography, so even if it is created,
maintained and distributed from liberal countries in Europe (where it is legal
to do this), it falls under certain export/import and/or
On Thu, Jun 07, 2001 at 01:09:28AM +0200, Sander Striker wrote:
> This will mean introducing a dependency on openssl
> for applications, (and until md5 is replaced by something
> that provides randomness, apr too).
That's the problem. I think introducing OpenSSL is going to be a big
nightmare for
I think the big reason for not ripping all the code out of Apache, is that
currently we don't require OpenSSL for a simple Apache install. If we rip
all of the crypto code out of APR, then we do introduce that dependancy.
OpenSSL is a rather large dependancy for just md5. :-)
Ryan
On Thu, 7 Ju
Why were the apr_file_printf switched to printf? printf isn't portable
or even supported by APR (so says Ryan). I'd rather we ate our own dog
food here. -- justin
On Wed, Jun 06, 2001 at 10:25:45PM -, [EMAIL PROTECTED] wrote:
> dreid 01/06/06 15:25:44
>
> Modified:test te
Hi all,
As if we weren't having enough discussion on this list
I'll throw in something else...
Could we consider _removing_ all crypto related code
from apr-util (and apr for that matter, since md5
still lives there)? Reason for asking is that there
already is an all purpose crypto library: opens
On Wed, Jun 06, 2001 at 06:33:34PM -0400, Cliff Woolley wrote:
>
> Can somebody remind me why it is that APR-util has 'buildconf.sh' and APR
> and Apache have just plain 'buildconf'? ISTR that we were going to
> migrate to 'buildconf.sh' and that it just only got done half-way. Is
> that right?
> -Original Message-
> From: Sander Striker [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 06, 2001 3:13 PM
> To: Cliff Woolley; David Reid
> Cc: APR Development List
> Subject: RE: cvs commit: apr/threadproc/unix thread.c
>
>
> > On Wed, 6 Jun 2001, David Reid wrote:
> >
> > > There
On Wed, Jun 06, 2001 at 05:34:42PM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Ian Holsman wrote:
>
> > should apr_checkmask be called apr_date_checkmask?
> >
> > mod_proxy uses it to do ap_checkmask(buf, "HTTP/#.# ###*")
>
> > > * @deffunc int apr_checkmask(const char *data, const char
> On Thu, 7 Jun 2001, Sander Striker wrote:
>
> > Argh!!! [getting abit frustrated now, because there seems to be no
> > way of moving forward and thus proving the system]
>
> I think we're at least starting to face the issues head-on. We're making
> progress, believe it or not. =-)
Yes we are!
I don't believe we were going to migrate to one or the other. They should
definately be the same thing. However, why we should change two when we
could change one is beyond me.
Ryan
On Wed, 6 Jun 2001, Cliff Woolley wrote:
>
> Can somebody remind me why it is that APR-util has 'buildconf.sh'
Can somebody remind me why it is that APR-util has 'buildconf.sh' and APR
and Apache have just plain 'buildconf'? ISTR that we were going to
migrate to 'buildconf.sh' and that it just only got done half-way. Is
that right?
Thanks,
Cliff
-
On Thu, 7 Jun 2001, Sander Striker wrote:
> Argh!!! [getting abit frustrated now, because there seems to be no
> way of moving forward and thus proving the system]
I think we're at least starting to face the issues head-on. We're making
progress, believe it or not. =-)
> > See, that's where my
> On Wed, 6 Jun 2001, David Reid wrote:
>
> > There is no pleasing some people is there??
>
> Nope. =-)
Argh!!! [getting abit frustrated now, because there seems to be no
way of moving forward and thus proving the system]
> > At present pools are a specific implementation of memory management.
On 6 Jun 2001 [EMAIL PROTECTED] wrote:
> If we don't have a lock and unlock function in an sms module then
> it's not an error as this is allowed. Add a comment to this effect
> to make it clearer.
>
>if (!mem_sys->lock_fn)
> -return APR_ENOTIMPL;
> +return APR_S
On Wed, 6 Jun 2001, Cliff Woolley wrote:
> newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)
>
> because then you have to be sure to
>
> apr_sms_free(str)
Make that apr_sms_free(newstr). ;-)
--
Cliff Woolley
[EMAIL PROTECTED]
On Wed, 6 Jun 2001, Ian Holsman wrote:
> should apr_checkmask be called apr_date_checkmask?
>
> mod_proxy uses it to do ap_checkmask(buf, "HTTP/#.# ###*")
> > * @deffunc int apr_checkmask(const char *data, const char *mask)
> > */
> > -APU_DECLARE(int) apr_checkmask(const char *data, co
On Wed, 6 Jun 2001, David Reid wrote:
> There is no pleasing some people is there??
Nope. =-)
> At present pools are a specific implementation of memory management. In
> time we hope to get sms to a point where we can replace pools with an sms
> module that is better. When we get there, it wo
should apr_checkmask be called apr_date_checkmask?
mod_proxy uses it to do ap_checkmask(buf, "HTTP/#.# ###*")
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 05, 2001 4:38 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr-util/test testda
There is no pleasing some people is there??
Here I go with an explanation of why I made the change...
At present pools are a specific implementation of memory management. In
time we hope to get sms to a point where we can replace pools with an sms
module that is better. When we get there, it wo
LARGEFILE support errors threw me into win32's mmap code. This got me looking
at the mmap bucket support. I'll accept we should never be dumping 4+GB out the
socket, but it opened my eyes to this quandry.
What ARE the offset and size arguments? If the mmap_create call sets aside a
maximum 'wind
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> On Wed, Jun 06, 2001 at 06:12:17PM -, [EMAIL PROTECTED] wrote:
> > - add an apr_pool_t to the sms structure
>
> -1 (non-veto, but awfully close). Uh, why are we doing this?
> I thought that a pool would be defined in terms of a sms (not now, bu
From: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 1:12 PM
> This threw up an issue with locking, so next
>
> - change the locking code to add an owner and ref counting
> so we can lock multiple times from the same thread. this was
> needed by the apr_sms_tracking_reset code
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Cc:
> On 6 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > -if (r->finfo.filetype) {
> > +if (r->finfo.filetype != APR_NOFILE) {
> >/* assume path_info already set */
>
> Wow, so we have APR_NOFILE _and_ APR_ENOFILE? That's awfully confusing,
On Wed, Jun 06, 2001 at 06:12:17PM -, [EMAIL PROTECTED] wrote:
> - add an apr_pool_t to the sms structure
-1 (non-veto, but awfully close). Uh, why are we doing this?
I thought that a pool would be defined in terms of a sms (not now, but
at some point). This would not allow that to happe
Apologies again for this being such a big commit :( I didn't want to commit
stuff before I'd finished, but kept finding more bits I had to do before I
was "finished".
Win32 and OS/2 need the changes I've made to the locking code...
david
On 6 Jun 2001, Jeff Trawick wrote:
> > Wow, so we have APR_NOFILE _and_ APR_ENOFILE? That's awfully confusing,
> > don't you think?
>
> err umm no real opinion as to confusability... one is an error code
> (APR_E*) and one isn't
Yeah, but if you're unfamiliar with the two and haven't actually go
Cliff Woolley <[EMAIL PROTECTED]> writes:
> On 6 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > -if (r->finfo.filetype) {
> > +if (r->finfo.filetype != APR_NOFILE) {
> > /* assume path_info already set */
>
> Wow, so we have APR_NOFILE _and_ APR_ENOFILE? That's awfully confusing,
> don
On 6 Jun 2001 [EMAIL PROTECTED] wrote:
> -if (r->finfo.filetype) {
> +if (r->finfo.filetype != APR_NOFILE) {
> /* assume path_info already set */
Wow, so we have APR_NOFILE _and_ APR_ENOFILE? That's awfully confusing,
don't you think?
--Cliff
> what's the profile of the memory allocation / reallocation / deallocation
> like?
>
> sander has written sma - smart memory allocator.
>
> it basically allows you to have more control over the block
> size etc for management etc of memory allocation / reallocation.
>
> it's wrapped through the
what's the profile of the memory allocation / reallocation / deallocation
like?
sander has written sma - smart memory allocator.
it basically allows you to have more control over the block
size etc for management etc of memory allocation / reallocation.
it's wrapped through the apr_sms memory AP
hi,
i need some help, and so i thought it best to ask here.
i am not subscribed to new-httpd@apache.org but i do
have post access, so if you reply, please cc me, but
i will keep an eye on the archives, just in case.
background
--
raph levien developed mod_virgule (which runs advogato.or
On Wed, 6 Jun 2001, Greg Stein wrote:
> Tough call. A POOL bucket is nominally "safer" than a HEAP bucket. But *IF*
> we are careful to ensure the HEAP bucket gets placed into a brigade, then we
> are guaranteed it will be tossed.
>
> That said, we've seen issues with malloc() efficiency in the bu
On Wed, 6 Jun 2001, Greg Stein wrote:
> The problem can be a little bit harder. Note that the two pools could be on
> disjoint branches of some other pool.
Yes, but you can treat that as no different from any other "not an
ancestor" case:
> P1
>/ \
> P2P3
As you sort of hinted at,
> The patch went in as we've been talking a lot about moving sms forward but
> we need stuff like locks and file access to start adding some of the things
> we'd like. Now we have it we can start fleshing out our ideas and probably
> add more code and modules.
so, let me try to [mentally] get thi
> The surprise comes in just how far reaching the apr_pool_t goes.
please:
identify the dependency chain. please.
if there's some automated code tools that help do this - i believe
that even VC++ may help, here - then all the better.
or source navigator, or code warrior, or your own perl sc
> (Attempt to) fix the build on Win32 from the sms-ified locks that David
> checked in earlier. This patch has a few things I don't quite like (eg,
> the macros are duplicated across the Unix/Win32 apr_private.h files),
but
> Greg has asked for an on-list discussion of David's original pat
raaay, good for sander.
HMAC_MD5 is used in NTLMv2 security to help guarantee
against replay attacks on different sessions
[NTLMv2 doesn't stop replay attacks on the _same_ session :)]
HMAC_xxx is used to generate one-way hashes from secret
keys and public data, basically. if you have to one-way
On Tue, Jun 05, 2001 at 11:25:43PM -0400, Cliff Woolley wrote:
> On Tue, 5 Jun 2001, Greg Stein wrote:
>...
> > The basic problem with the current setaside() function is that it doesn't
> > say *how long* the set-aside bucket should be able to live. Thus, it must
> > implement logic to "live foreve
On Tue, Jun 05, 2001 at 11:35:33PM -0400, Cliff Woolley wrote:
> On Tue, 5 Jun 2001, Justin Erenkrantz wrote:
> > With you up until here, but how does the pool know that it won't live as
> > long as another pool? If a pool is a child of a pool, then we know that
> > it won't last as long as its pa
On Tue, 5 Jun 2001 20:37:41 -0700, Justin Erenkrantz wrote:
>On Wed, Jun 06, 2001 at 03:33:46AM -, [EMAIL PROTECTED] wrote:
>> bjh 01/06/05 20:33:46
>>
>> Modified:uri Makefile.in
>> Log:
>> Need to specify libtool objects so libtool is used to compile.
>>
>> Revis
On Wed, Jun 06, 2001 at 03:33:46AM -, [EMAIL PROTECTED] wrote:
> bjh 01/06/05 20:33:46
>
> Modified:uri Makefile.in
> Log:
> Need to specify libtool objects so libtool is used to compile.
>
> Revision ChangesPath
> 1.5 +1 -1 apr-util/uri/Makefile.i
On Tue, 5 Jun 2001, Justin Erenkrantz wrote:
> With you up until here, but how does the pool know that it won't live as
> long as another pool? If a pool is a child of a pool, then we know that
> it won't last as long as its parent?
A pool is guaranteed to live at least as long as all its childr
On Tue, 5 Jun 2001, Greg Stein wrote:
> Problem: let's say that filter FOO caused the setaside(). Further, let's say
> it did this using ap_save_brigade(). Looking at that function, we see that
> it ignores APR_ENOTIMPL returns from setaside(). For the FILE case, that
> bungs us up horribly. That
On Tue, Jun 05, 2001 at 05:45:15PM -0700, Greg Stein wrote:
> Now, setaside(pool):
>
> In this case, let's say that filter FOO is a (main) request filter and is
> doing a setaside. It calls setaside(r->pool). The FILE bucket has its own
> pool (this happens to be subreq->pool), so it calls some po
On Tue, Jun 05, 2001 at 01:49:39PM -0700, Ian Holsman wrote:
> > -Original Message-
> > From: Greg Stein [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 04, 2001 3:18 PM
> > To: new-httpd@apache.org
> > Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18
>...
> > Passing a pool to s
51 matches
Mail list logo
