[EMAIL PROTECTED] writes:
> wsanchez2002/11/28 23:21:07
>
> Modified:server .cvsignore Makefile.in
>.acinclude.m4
> Log:
> If apr and apr-util are not in-tree, we need to be able to find the
> include directory for each in order to generate the server/exp
[EMAIL PROTECTED] writes:
> wsanchez2002/11/29 03:05:59
>
> Modified:.Tag: APACHE_2_0_BRANCH CHANGES acinclude.m4
> buildconf configure.in
>buildTag: APACHE_2_0_BRANCH binbuild.sh
>modules/aaa Tag: APACHE_2_0_BRANCH con
Since the relatively few people who voted left us at an impasse on
this, it seems appropriate to try to find a compromise. (I've been
told before that something other than normal RTC-with-3-+1 vs. CTR
isn't the Apache way or something to that effect, but I don't see that
such concerns should stand
At 06:47 AM 12/2/2002, Jeff Trawick wrote:
>[EMAIL PROTECTED] writes:
>
>> wsanchez2002/11/29 03:05:59
>>
>> Modified:.Tag: APACHE_2_0_BRANCH CHANGES acinclude.m4
>> buildconf configure.in
>>buildTag: APACHE_2_0_BRANCH binbuild.sh
>>
Linux (2.4.18 and 2.4.19, for me anyway) with apache versions
2.0.40 to 2.0.43 (that I've tested anyways) is broken with
TCP_CORK and IPv6. Bizarrely v6 requests will work the first
few times and then start failing, typically you just wont get
a response from the server. Though strace shows that i
Any reason why the changes to the following source file should not be added to the
2.0.44 branch?
modules/experimental/mod_cache.c
modules/experimental/mod_cache.imp
modules/experimental/util_ldap.c
modules/experimental/util_ldap.dsp
modules/generators/mod_cgi.c
modules/generators/mod_cgid.c
modu
> Linux (2.4.18 and 2.4.19, for me anyway) with apache versions
> 2.0.40 to 2.0.43 (that I've tested anyways) is broken with
> TCP_CORK and IPv6. Bizarrely v6 requests will work the first
> few times and then start failing, typically you just wont get
> a response from the server. Though strace sho
Humm... should we have a runtime check instead? Folks might want to use the
same executable for both ipv4 and ipv6 traffic.
Bill
>
> > Linux (2.4.18 and 2.4.19, for me anyway) with apache versions
> > 2.0.40 to 2.0.43 (that I've tested anyways) is broken with
> > TCP_CORK and IPv6. Bizarrely v6
* Joshua Slive wrote:
> On Sat, 30 Nov 2002, André Malo wrote:
>> *sigh*. And I thought, I've got it now ;-) (2.0 = keep old, 2.1 introduce
>> new)
>
> Ok. Now it appears this is exactly what we are doing.
I hope I didn't force that anyway, although... hmm ;-)
> Andre, do you want
> to take ch
Colm MacCarthaigh <[EMAIL PROTECTED]> writes:
> Linux (2.4.18 and 2.4.19, for me anyway) with apache versions
> 2.0.40 to 2.0.43 (that I've tested anyways) is broken with
> TCP_CORK and IPv6. Bizarrely v6 requests will work the first
> few times and then start failing, typically you just wont get
Sounds good to me. I'd prefer adding "about four days".
I'm also assuming that you are only talking about big commits
(anything other than a few lines). I wouldn't want things like
typos to have to wait that long. This is grey area though,
and it comes down to personal judgement...so I agree with
Sounds like lazy consensus under RTC to me :)
Aaron Bannert wrote:
>
> Sounds good to me. I'd prefer adding "about four days".
>
> I'm also assuming that you are only talking about big commits
> (anything other than a few lines). I wouldn't want things like
> typos to have to wait that long. Thi
Henri Gomez <[EMAIL PROTECTED]> writes:
> Jeff Trawick wrote:
> > Henri Gomez <[EMAIL PROTECTED]> writes:
> >
> >>The module should create some threads at startup time,
> >>these threads will handle dbm and IO operations and
> >>they should be kept running after the module initialisation.
> >>
> >
In httpd-2.0, mod_dir uses ap_internal_fast_redirect once it has found
an appropriate file from the DirectoryIndex list. This change makes it
impossible to use mod_rewrite's proxypass feature on an index file.
mod_dir finds the file, but returns its source instead of the output of
the proxypass
"Brad Nicholes" <[EMAIL PROTECTED]> writes:
> Any reason why the changes to the following source file should not
> be added to the 2.0.44 branch?
...
> modules/generators/mod_cgi.c
> modules/generators/mod_cgid.c
...
> server/listen.c
I'll try to merge these tonight.
There is no sense in making
I'll take a look at the mod_cache changes.
Bill
> -Original Message-
> From: Brad Nicholes [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 02, 2002 12:28 PM
> To: [EMAIL PROTECTED]
> Subject: 2.0.44 changes...
>
>
> Any reason why the changes to the following source file should not
I already took care of mod_cache.imp since it is a NetWare export list file.
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> [EMAIL PROTECTED] Monday, December 02, 2002 4:08:34 PM >>>
I'll take a look at the mod_cache
At 11:27 AM 12/2/2002, Brad Nicholes wrote:
>Any reason why the changes to the following source file should not be added to the
>2.0.44 branch?
>
>modules/experimental/util_ldap.c
That patch looks good... committed.
>modules/experimental/util_ldap.dsp
And this patch was very bad. Already rever
Ok... last call for 2.0.44 ...
My understanding of our apr-util library 'thunks' is that we want all
platforms to just 'play nice' and use their built-in support. We do have
that on WinNT flavors after 4.0, as a download for 4.0 and with some
great effort for 9x LDAP users. I suspect that our au
At 11:24 PM 12/2/2002, William A. Rowe, Jr. wrote:
>Patches attached.
Well... best of intentions... here are corrected patches - the httpd
patch was most borked, both with respect to util_ldap.dsp and my
most recent changes to Apache.dsw. Sorry... try these, win32
hackers.
Bill
Index: aprutil.ds
I *can't* win for losing. Correct win32_auth_ldap.patch - finally.
At 11:24 PM 12/2/2002, William A. Rowe, Jr. wrote:
>Patches attached.
Well... best of intentions... here are corrected patches - the httpd
patch was most borked, both with respect to util_ldap.dsp and my
most recent changes to Ap
21 matches
Mail list logo
