On Thu, Aug 23, 2001 at 11:54:46PM -0700, Roy T. Fielding wrote:
> > who's job is it to answer an M_OPTIONS request? Every module's? Then the mod_cgi
> > family is broken (this is what led me to discover that viewcvs.cgi hangs on HEAD,
> > maybe other cgi's are hanging, as well.)
>
> In this ca
On Thu, 23 Aug 2001, Roy T. Fielding wrote:
> As I recall, libtool modifies the runtime library path within the exec
> when it installs the file, or something like that.
libuncooltool. i didn't realize libapr was now linked as a shared
library. that explains everything.
On Fri, Aug 24, 2001 at 03:01:35AM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> I just built and compiled using the prefork model (without wrapping of the
> APR_HAS_THREADS - and it works !!..
>
> The ssl_util_thr_id() will be registered only if the MPM is threaded.
> However, the sy
On Fri, 24 Aug 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> I just built and compiled using the prefork model (without wrapping of the
> APR_HAS_THREADS - and it works !!..
>
> The ssl_util_thr_id() will be registered only if the MPM is threaded.
> However, the symbol apr_os_thread_cu
I just built and compiled using the prefork model (without wrapping of the
APR_HAS_THREADS - and it works !!..
The ssl_util_thr_id() will be registered only if the MPM is threaded.
However, the symbol apr_os_thread_current is available in libapr.a -
irrespective of threaded / prefork model !!!..
> It should be placed via make install by "libtool --mode=install" now.
> I'd have to see if the act of installation changes the file - I only
> thought it helped copy the right file. If it changes it, blech.
As I recall, libtool modifies the runtime library path within the exec
when it ins
> who's job is it to answer an M_OPTIONS request? Every module's? Then the mod_cgi
> family is broken (this is what led me to discover that viewcvs.cgi hangs on HEAD,
> maybe other cgi's are hanging, as well.)
In this case, it is the responsibility of each CGI. That has always been
the case fo
On Thu, Aug 23, 2001 at 11:15:44PM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> +static unsigned long ssl_util_thr_id()
> +{
> +return (unsigned long) apr_os_thread_current();
> +}
> +
This needs to be protected by #if APR_HAS_THREADS. -- justin
Cool.. I'll look into those warnings..Also, a lot of the function prototypes
are still not defined in mod_ssl.h - or atleast they don't have a forward
declaration.. I was thinking of looking into those issues also..
Thanks
-Madhu
-Original Message-
From: Doug MacEachern
To: MATHIHALLI,M
On Thu, 23 Aug 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> Hi,
> I'd missed out the CRYPRO_thread_id stuff in my earlier patch .. Here it
nice.
> -static void ssl_util_thread_locking_callback(int mode, int type,
> - const char *file, i
Hi !
Can u let me know the ay to unsubscribe from the list ?
Thanks
Bhoopendra
Hi,
I'd missed out the CRYPRO_thread_id stuff in my earlier patch .. Here it
comes :
Index: ssl_util.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_util.c,v
retrieving revision 1.14
diff -u -r1.14 ssl_util.c
--- ssl_util.
On Thu, 23 Aug 2001, Justin Erenkrantz wrote:
> If you created the locks as INTRAPROCESS before fork()ing new children,
> would each children's copy of the lock be isolated? Maybe. If so,
> then the post_config hook works, but I think child_init makes a bit
> more sense. But, that's me. -
On Thu, Aug 23, 2001 at 10:42:16PM -0700, Doug MacEachern wrote:
> > IMHO, the call to ssl_util_thread_setup should be moved to
> > ssl_init_Child and even potentially surrounded by
> > #if APR_HAS_THREADS. -- justin
>
> why child init rather than module init?
> i did turn off the locking unle
(hmm, original reply never showed up...)
Date: Thu, 23 Aug 2001 21:26:51 -0700 (PDT)
From: Doug MacEachern <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Re: FW: [PATCH] towards achieving thread-safetyness in mod_ssl
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL
On Thu, 23 Aug 2001, Justin Erenkrantz wrote:
> I meant to review this patch, but I accidentally hit the delete key on
> the original message. Anyway, that APR_LOCKALL can be APR_INTRAPROCESS.
> We're only concerned about safety within our process not across
> multiple processes - there is no
On Thu, Aug 23, 2001 at 10:34:29PM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> Yes.. APR_LOCKALL can be replaced by APR_INTRAPROCESS.. I've done that
> change and also have introduced CRYPTO_dynamic locks.. I shall send that
> patch soon..
FWIW, I tried CRYPTO_dynamic locks in flood
On Thu, 23 Aug 2001, Doug MacEachern wrote:
> On Fri, 24 Aug 2001, Cliff Woolley wrote:
>
> funny, i tried committing a change to mod_include.c and up-to-date failed,
> was the same indentation fix. then i was going to suggest this patch to
> cure the same problem, since any valid (non "generate
Yes.. APR_LOCKALL can be replaced by APR_INTRAPROCESS.. I've done that
change and also have introduced CRYPTO_dynamic locks.. I shall send that
patch soon..
Thanks
-Madhu
-Original Message-
From: Justin Erenkrantz
To: [EMAIL PROTECTED]
Sent: 8/23/01 10:28 PM
Subject: Re: cvs commit: http
On Thu, 23 Aug 2001, Justin Erenkrantz wrote:
> libtool --version? -- justin
% libtool --version
ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
On Fri, 24 Aug 2001, Cliff Woolley wrote:
funny, i tried committing a change to mod_include.c and up-to-date failed,
was the same indentation fix. then i was going to suggest this patch to
cure the same problem, since any valid (non "generated") uri should start
with a '/'.
Index: modules/filte
On Fri, Aug 24, 2001 at 04:08:04AM -, [EMAIL PROTECTED] wrote:
> +*lock_cs = apr_palloc(p, CRYPTO_NUM_LOCKS);
> +for (i = 0; i < CRYPTO_NUM_LOCKS; i++)
> +{
> +lock_count[i]=0;
> +apr_lock_create(&(lock_cs[i]), APR_MUTEX, APR_LOCKALL,
> +
On Thu, Aug 23, 2001 at 10:05:41PM -0700, Justin Erenkrantz wrote:
> On Fri, Aug 24, 2001 at 01:02:58AM -0400, Cliff Woolley wrote:
> > On 24 Aug 2001 [EMAIL PROTECTED] wrote:
> >
> > > wrowe 01/08/23 21:41:47
> > >
> > > Log:
> > >
> > >
> >
> > WTF?
>
> Maybe committed as daedalus was
On Fri, 24 Aug 2001, Cliff Woolley wrote:
> if (strncmp(rnew->filename, fdir, fdirlen) != 0
>&& rnew->filename[fdirlen]
>&& ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
>
> This is not new behavior ... it's been around since rev 1.1 of request.c.
Actually, upon
Hi,
I have made an external module in PHP and trying to work and output on
the web browser using apache.
I am using Apache 1.13.20, the latest available. and PHP 4.0.6. O.S. :
Red Hat Linux 7.1
When accessing through the browser its not able to load the page. The
error logs saw this error.
http
httpd-test revealed a bug in processing recursive includes for
relative-pathed files. This patch fixes it, but it seems suboptimal... is
there are a faster way to test for this condition than doing a strcmp?
(PS: sorry about the line wraps.)
The problem is just that server/request.c sets rnew->
On Fri, Aug 24, 2001 at 01:02:58AM -0400, Cliff Woolley wrote:
> On 24 Aug 2001 [EMAIL PROTECTED] wrote:
>
> > wrowe 01/08/23 21:41:47
> >
> > Log:
> >
> >
>
> WTF?
Maybe committed as daedalus was kicked? I dunno.
But, our mail server here at eBuilt kicked the bucket around the same
t
On Thu, Aug 23, 2001 at 09:47:36PM -0700, Doug MacEachern wrote:
> if i edit/save filepath.c and make, everything relinks and i still have
> the same problem. after 'make install', the installed binary works as
> expected, as does .libs/httpd. but, change a file, run 'make', appears to
> relink
On 24 Aug 2001 [EMAIL PROTECTED] wrote:
> wrowe 01/08/23 21:41:47
>
> Log:
>
>
WTF?
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, Aug 23, 2001 at 09:31:57PM -0700, Doug MacEachern wrote:
> why is the installed httpd different from .libs/httpd?
>
> % ls -l ~/ap/prefork/bin/httpd
> -rwxr-xr-x1 dougmdougm 4318551 Aug 23 21:11
>
> % ls -l .libs/httpd
> -rwxr-xr-x1 dougmdougm 4318583 Aug 23 21:2
whoops, file sizes are the same, i made a change before make install
again. but i still have the same problem, they are still different
somehow. i had done this:
make distclean
cvs up
buildconf
configure ... && make depend && make
yet somehow (note warning):
(gdb) b apr_filepath_root
Breakpoi
Here is where things stand (as I go off to bed to clear my brain)...
There is something odd in mod_negotiation, beyond getting 406's on top
of errors, that I need to trace in the morning. It is definately related to
the change to buffered code, but I'm not sure if it's mod_negotiation, or
the ap
This introduces a bug...
Revision 1.74 / (download) - annotate - [select for diffs] , Fri Aug 24 03:04:44 2001
UTC (79 minutes, 1 second ago) by trawick
Branch: MAIN
Changes since 1.73: +1 -1 lines
Diff to previous 1.73 (colored)
buffer .var maps to avoid asking the kernel for one byte at a
time
why is the installed httpd different from .libs/httpd?
% ls -l ~/ap/prefork/bin/httpd
-rwxr-xr-x1 dougmdougm 4318551 Aug 23 21:11
% ls -l .libs/httpd
-rwxr-xr-x1 dougmdougm 4318583 Aug 23 21:21 .libs/httpd*
i normally don't "make install" everytime i'm working on a chan
Already has been. You have .locks files since someone was committing at that
exact instant. I suspect the next tarball won't suffer this problem, and we
will have to rm that directory from the tree, once we feel safe (2 weeks or
so) that everyone updated their trees to knock out this duplication
Netware, Win32, and OS2 are threaded architectures.
mod_unique_id is ugly, it made several presumptions based on the pid,
which is essentially broken on these other platforms.
If you look at the 2.0 repository, I believe we've gotten around to fixing
these broken assumptions. But Netware, OS2 a
Hi,
when I extract the apr-x.tar.gz file fetched from
http://cvs.apache.org/snapshots/apr/ I get a message about overwriting files in the
./locks/netware dir.
Looking at http://cvs.apache.org/viewcvs.cgi/apr/locks/ only shows a 'netware' dir,
but when I open the *.tar.gz with WinZip, I can
Hi,
I've compiled mod_unique_id for Win32 and for Netware, and on both platforms it seems
to work the same as with Unix, I can see a unique id with SSI and cgi scripts; so can
someone please explain why we have the #error about not supporting multitask OS?
Thanks, Guenter.
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 8:40 PM
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > That isn't all, but I'm still coding. Please (everyone) don't slap patches
> > willy nilly on this, I'm uncovering a ton of loose ends in our
> > existing
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> That isn't all, but I'm still coding. Please (everyone) don't slap patches
> willy nilly on this, I'm uncovering a ton of loose ends in our
> existing code
what's good for the goose is good for the gander ;)
--
Jeff Trawick | [EMAIL PROTECT
On Thu, 23 Aug 2001, William A. Rowe, Jr. wrote:
> The reason you observed this was the fact that &dir is passed to
> apr_filepath_root _because_ we want that dir pointer moved forward.
> The patch I applied to set aside the caller's *dir value has fixed
> this part.
Your patch didn't help on my
The reason you observed this was the fact that &dir is passed to apr_filepath_root
_because_ we want that dir pointer moved forward. The patch I applied to set
aside the caller's *dir value has fixed this part.
That isn't all, but I'm still coding. Please (everyone) don't slap patches
willy nil
> On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote:
> >...
> > However, the bugs are getting more subtle and take longer to debug and
> > fix. With our current process, a great deal of new code can be
> > committed while the gnarly problem in last tarball is being debugged.
> > Why woul
current cvs default_handler is failing for pages that exist. problem is
due to ap_os_is_path_absolute() return false (in directory_walk), when the
path is in fact absolute, so get_path_info() never happens, leaving
r->finfo.filetype == 0. am i the only one seeing this? patch below
fixes here.
From: "Greg Stein" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 6:21 PM
Subject: Re: Letting Table store non-char data
> On Thu, Aug 23, 2001 at 07:50:03AM -0500, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <[EMAIL PROTECTED]>
> > Sent: Thursday, August 23,
I'm on it... (just got back)... it should be fixed in an hour.
- Original Message -
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 6:07 PM
Subject: Re: Win32 compile breakage...
> On Thu, 23 Aug 2001, William A. Rowe, Jr. wrote:
>
> >
open("/usr/local/apache2/error/HTTP_NOT_FOUND.html.var",0,0666) = 9 (0x9)
read(0x9,0xbfbfb1f0,0x1) = 1 (0x1)
read(0x9,0xbfbfb1f1,0x1) = 1 (0x1)
read(0x9,0xbfbfb1f2,0x1) = 1 (0x1)
read(0x9,0xbfbfb1f3,0x1)
On 23 Aug 2001, Jeff Trawick wrote:
> > core.c: In function `ap_core_translate':
> > core.c:2921: warning: statement with no effect
> > core.c:2936: warning: statement with no effect
> > mod_include.c: In function `split_and_pass_pretag_buckets':
> > mod_include.c:122: warning: control reaches en
On Fri, Aug 24, 2001 at 01:22:42AM +0200, Graham Leggett wrote:
> [EMAIL PROTECTED] wrote:
>
> > jerenkrantz01/08/20 13:44:43
> >
> > Modified:contributors index.html
> > Log:
> > slive's commit reminded me that I should probably add my own info.
>
> What are the criteron for bein
Cliff Woolley <[EMAIL PROTECTED]> writes:
> Uhmm... it's not just Win32. I can't even access the default "it worked"
> page on Linux--not quite, anyway.
>
>
> First I tried just /
>
> [Thu Aug 23 18:59:00 2001] [error] [client 128.143.136.188] Negotiation:
> discovered file(s) matching reques
Cliff Woolley <[EMAIL PROTECTED]> writes:
> Crap, and I saw those (briefly), too... I thought they looked strange for
> some reason but didn't focus on it long enough to see the obvious. I
> wonder why the hell didn't this cause a gcc warning?
>From a regression test report:
/home/regress/regr
Graham Leggett <[EMAIL PROTECTED]> writes:
> Jeff Trawick wrote:
>
> > > +module AP_MODULE_DECLARE_DATA tcache_module;
> >
> > Why isn't this "cache_module" instead of "tcache_module"? I'm getting
> > unresolved references to cache_module from modules.c.
>
> Because cache_module was already
On 23 Aug 2001 [EMAIL PROTECTED] wrote:
> trawick 01/08/23 16:49:41
>
> Modified:server core.c
> Log:
> fix fubar with recent commit to ap_core_translate()
>
>}
> -r->canonical_filename == r->filename;
> +r->canonical_filename = r->filename;
>
Jeff Trawick wrote:
> > +module AP_MODULE_DECLARE_DATA tcache_module;
>
> Why isn't this "cache_module" instead of "tcache_module"? I'm getting
> unresolved references to cache_module from modules.c.
Because cache_module was already taken.
Ideally it should be cache_module...
Regards,
Grah
[EMAIL PROTECTED] wrote:
> jerenkrantz01/08/20 13:44:43
>
> Modified:contributors index.html
> Log:
> slive's commit reminded me that I should probably add my own info.
What are the criteron for being listed here...?
Regards,
Graham
--
-
[
On Thu, Aug 23, 2001 at 07:50:03AM -0500, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Thursday, August 23, 2001 2:37 AM
>
>
> > On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
> > > Greg Stein wrote:
> > >...
> > > >Yes there is. apr_pool_userdata_set
On Thu, Aug 23, 2001 at 07:07:26PM -0400, Cliff Woolley wrote:
> Uhmm... it's not just Win32. I can't even access the default "it worked"
> page on Linux--not quite, anyway.
Yup. Seeing the same thing on Solaris. I can't get to any pages.
I'm bogged down by other stuff right now, so I can't lo
On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote:
>...
> However, the bugs are getting more subtle and take longer to debug and
> fix. With our current process, a great deal of new code can be
> committed while the gnarly problem in last tarball is being debugged.
> Why would we think t
On Thu, 23 Aug 2001, William A. Rowe, Jr. wrote:
> From: "Bill Stoddard" <[EMAIL PROTECTED]>
> Sent: Thursday, August 23, 2001 5:42 PM
>
>
> > HEAD is compiling now. Somehow managed to get the wrong awk.exe
> > wrapping the wrong gawk.exe. I must have extracted right in the
> > middle of your la
Dear [EMAIL PROTECTED],
I'M NOT KNOW IF I AM WRIGHT IN THE ML BUT I NEED HELP
we got an problem with ie-clients which had frontpage installed.
we have a .htaccess dir in which are dirs with downloadable files
if the ie client tries to download a file in the log you can see
that "Data
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 5:42 PM
> HEAD is compiling now. Somehow managed to get the wrong awk.exe wrapping the wrong
> gawk.exe. I must have extracted right in the middle of your last update. All seems
>to be
> working now.
Win32 is being flak
This bit of logic in includes_filter() in mod_include looks
like a security hole:
if (r->method_number != M_GET) {
return ap_pass_brigade(f->next, b);
}
It's possible to see the unparsed content of a file by just POSTing to it...
--Brian
HEAD is compiling now. Somehow managed to get the wrong awk.exe wrapping the wrong
gawk.exe. I must have extracted right in the middle of your last update. All seems to
be
working now.
Bill
> Is awk installed?
>
> - Original Message -
> From: "Bill Stoddard" <[EMAIL PROTECTED]>
> To: <
On Thu, Aug 23, 2001 at 09:08:43AM -0700, Justin Erenkrantz wrote:
> The question is where should this go. Should we have
> test.httpd.apache.org? Or should I just slap info on httpd.apache.org?
The convention I've seen in Jakartaland is to use
http://jakarta.apache.org/module/
From: "Lars Eilebrecht" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 4:47 PM
> According to Martin Kraemer:
>
> > In other words, I propose to move /manual up one directoryy level,
> > side by side with /icons:
> > @@ServerRoot@@/htdocs/...
> > @@ServerRoot@@/icons/...
> >
On Thu, 23 Aug 2001, Lars Eilebrecht wrote:
>
> This makes sense, but then we should move htdocs/error/ one
> level up, too. IMHO the server root gets cluttered up more and more
> if we do this.
OtherBill already moved the error directory.
Joshua.
According to Martin Kraemer:
> In other words, I propose to move /manual up one directoryy level,
> side by side with /icons:
> @@ServerRoot@@/htdocs/...
> @@ServerRoot@@/icons/...
> @@ServerRoot@@/manual/...
This makes sense, but then we should move htdocs/error/ one
level up, too
One of the bottlenecks in mod_include is the setting of
environment variables in add_include_vars(). This patch
defers the evaluation of the more computationally expensive
variables (user name and various timestamps) until/unless
they're actually used. With this change, I'm seeing a ~5%
throughp
> > Both should be able to handle it. Basically, the default handler should
> > do it if nobody else does. But, modules should be allowed to handle
> > M_OPTIONS requests.
>
> So what you are saying, if I understand, is that a module _may_ handle
> M_OPTIONS, but it _MUST_ return DECLINED if it
From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 4:05 PM
> > Because I'm less than clear on the subject, so I will ask (now that you've
> > reminded me)...
> >
> > who's job is it to answer an M_OPTIONS request? Every module's? Then the
> > mod_cgi family is broken (this i
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:42 PM
> On 23 Aug 2001 [EMAIL PROTECTED] wrote:
>
> > wrowe 01/08/23 12:42:44
> >
> > Modified:modules/ssl mod_ssl.h ssl_engine_config.c ssl_engine_init.c
> > Log:
> > Add some appropriate constness to
Is awk installed?
- Original Message -
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:18 PM
Subject: Win32 compile breakage...
> Dies really quick... Any thoughts as to what the problem might be? This after a fresh
> checkout of HEAD
On Thursday 23 August 2001 13:53, William A. Rowe, Jr. wrote:
> From: <[EMAIL PROTECTED]>
> Sent: Thursday, August 23, 2001 3:29 PM
>
> > trawick 01/08/23 13:29:47
> >
> > Modified:modules/mappers mod_negotiation.c
> > Log:
> > please no // in Apache code... it doesn't compile everyw
just use ap_strchr_c instead of ap_strchr.
Ryan
On Thursday 23 August 2001 13:42, Cliff Woolley wrote:
> On 23 Aug 2001 [EMAIL PROTECTED] wrote:
> > wrowe 01/08/23 12:42:44
> >
> > Modified:modules/ssl mod_ssl.h ssl_engine_config.c
> > ssl_engine_init.c Log:
> > Add some appropr
From: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:29 PM
> trawick 01/08/23 13:29:47
>
> Modified:modules/mappers mod_negotiation.c
> Log:
> please no // in Apache code... it doesn't compile everywhere
>
> a note about why it is commented out would be appropriate too
Agreed. Thanks for all the thoughts!
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: [EMAIL PROTECTED]
> -Original Message-
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 23, 2001 11:57 AM
> To: [EMAIL PROTECTED]; MATHIHALLI
On 23 Aug 2001 [EMAIL PROTECTED] wrote:
> wrowe 01/08/23 12:42:44
>
> Modified:modules/ssl mod_ssl.h ssl_engine_config.c ssl_engine_init.c
> Log:
> Add some appropriate constness to the config
>
> Revision ChangesPath
> 1.30 +17 -17httpd-2.0/modules/ssl/mod_ssl
On Thu, 23 Aug 2001, Cliff Woolley wrote:
> Like I said before, I'm still +1 for 2.0.24 for beta on Unix. I don't
> much like the idea of calling it a beta only on Unix, but I won't veto the
> idea.
I'm +1 for a 2.0.24 beta as well. I'm +1 for beta for anything that
a) compiles
b) has no known
Dies really quick... Any thoughts as to what the problem might be? This after a fresh
checkout of HEAD.
Configuration: libapr - Win32 Debug
Performing Custom Build Step on .\include\apr.hw
Created apr.h from apr.hw
Creating Version Resource
Error executing
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> Just tried a new extract of HEAD and the server doesn't even build.
Yep, same here. I'll jump right in to that.
> Which is pretty much what I expected. At some point, we need to make
> binaries available so the world can take a look at what we are
> On Thu, 23 Aug 2001, Bill Stoddard wrote:
>
> > > I don't think I am. Let's get this taken care of. :-/
> >
> > Why? Most serious Apache users run Unix/Linux. And thread support
> > under Unix/Linux is one of the main features of Apache 2.0. Obviously
> > we need to fix Win32 but it is wrong t
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 2:16 PM
> Besides, I just think it looks bad for us to constantly be swaying back
> and forth. Oh, this release is a beta for Unix but not Win32. Oh, this
> one is good on Win32 but only alpha-and-a-half for Unix.
Not
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> > I don't think I am. Let's get this taken care of. :-/
>
> Why? Most serious Apache users run Unix/Linux. And thread support
> under Unix/Linux is one of the main features of Apache 2.0. Obviously
> we need to fix Win32 but it is wrong to delay the b
> On Thu, 23 Aug 2001, Bill Stoddard wrote:
>
> > > I'm -1 on calling any Win32 release a beta without those eliminated
> >
> > I'm okay with only declaring beta on Unix/Linux.
>
> I don't think I am. Let's get this taken care of. :-/
>
Why? Most serious Apache users run Unix/Linux. And threa
Ryan Bloom wrote:
>
> I disagree quite strongly. Take a look at the CHANGES file for 2.0.25.
> We have fixed at least on seg fault in mod_mime, a memory leak in
> mod_mime_magic, and two major fixes to the build system.
>
> 2.0.25 is far better than 2.0.24,
It may be better, but that remains
Right now, that's all built in InstallShield for Windows Installer 2.0 (ISWI).
Someday (sooner? later?) it would be nice to move it out of that product, which
makes a terrific IDE but sometimes has less than desireable amount of control.
- Original Message -
From: "Günter Knauf" <[EMAIL
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> > I'm -1 on calling any Win32 release a beta without those eliminated
>
> I'm okay with only declaring beta on Unix/Linux.
I don't think I am. Let's get this taken care of. :-/
--Cliff
--
> I'm -1 on calling any Win32 release a beta without those eliminated
I'm okay with only declaring beta on Unix/Linux.
Bill
[EMAIL PROTECTED] writes:
> Index: mod_cache.c
> +module AP_MODULE_DECLARE_DATA tcache_module;
Why isn't this "cache_module" instead of "tcache_module"? I'm getting
unresolved references to cache_module from modules.c.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
We must (temporarily) disable the /error/ mapping section, until we can set
ForceLanguagePreferences Full
because right now you can get a Not Acceptable [list of identical files] that
they can't decypher. I should be wrapped up tommorow, but I've been seriously
sidelined by bigger fish...
[EMAIL PROTECTED] writes:
> Index: mod_include.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
> retrieving revision 1.128
> retrieving revision 1.129
> diff -u -r1.128 -r1.129
> --- mod_include.
-
> On Thu, 2001-08-23 at 11:07, Jeff Trawick wrote:
> > [EMAIL PROTECTED] writes:
> apr_uri_components got renamed to apr_uri_t
>
Ahh... I was developing off a slightly stale development tree. Updating now...
Bill
Sending it again, as I had sent it to the old address earlier.. (sorry if
it's a duplicate)
Thanks
-Madhu
-Original Message-
From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 10:24 AM
To: '[EMAIL PROTECTED]'
Subject: [PATCH] towards
>
> What in the world is apr_uri_components? Should I be searching in
> files other than '*.c' and '*.h' to find it? gcc can't find it
> either.
>
> make[3]: Entering directory `/home/trawick/apache/httpd-2.0/modules/experimental'
It's in apr-util/include/apr_uri.h
Unless it has been moved/r
On Thu, 2001-08-23 at 11:07, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
apr_uri_components got renamed to apr_uri_t
>
> > Index: mod_cache.c
> > ===
> > RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
> >
[EMAIL PROTECTED] writes:
> Index: mod_cache.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -u -r1.6 -r1.7
> --- mod_cache.c 200
Hi,
A first step towards achieving the thread-safetyness of the mod_ssl
code - ensure that the SSL library (OpenSSL) has all the locking mechanisms
that are needed for thread-safety. It'd be great if somebody could review
the code and commit it accordingly..
Pl. let me know your co
On Thu, 2001-08-23 at 09:33, Bill Stoddard wrote:
> What is the failure? And why was this not broken in Apache 1.3? The change seems
> reasonable but curious if there is a better way to fix this.
the failure happens in ap_escape_html as it always assumes a not-null
value being passed in.
to rep
> In other words, I propose to move /manual up one directoryy level,
> side by side with /icons:
>@@ServerRoot@@/htdocs/...
>@@ServerRoot@@/icons/...
>@@ServerRoot@@/manual/...
> Then we really don't need to worry about overwriting the /manual
> directory during installation (we don't
"Atur Shah" <[EMAIL PROTECTED]> writes:
> When accessing through the browser its not able to load the page. The
> error logs saw this error.
> (http://localhost/) and (http://localhost/) works
> fine.
>
> httpd: wcsrtombs.c:116: __wcsrtombs: Assertion `data.outbuf != (unsigned
> char *) dst' fai
1 - 100 of 157 matches
Mail list logo
