Re: cvs commit: httpd-2.0/modules/ldap util_ldap_cache_mgr.c

Ah Yes, it would be good to have the same fix in both branches. Sorry -- I overlooked this... -- Jess Holle Brad Nicholes wrote: Even though it isn't a big deal, the point is that newcurl is not undefined. It was initialized to NULL when it was declared at the beginning of the

Possible error in apr_rgetline_core

Lines 250-263 of server/protocol.c: 250/* Would this overrun our buffer? If so, we'll die. */ 251if (n bytes_handled + len) { 252*read = bytes_handled; 253if (*s) { 254/* ensure this string is terminated */ 255if

Re: Possible error in apr_rgetline_core

On Tue, Sep 21, 2004 at 10:00:48AM -0500, Rici Lake wrote: The first time through this loop, bytes_handled will be 0. If the buffer was provided, rather than being allocated by ap_rgetline_core, and the first read exceeded the maximum length (n), then line 256 will set the byte *before* the

Re: Possible error in apr_rgetline_core

On 21-Sep-04, at 11:03 AM, Joe Orton wrote: pass 2: bytes_handled = 8191, *s = 8191-byte region Quite right: I hadn't looked closely enough at the case where there was no user-supplied buffer :( Ok, bytes_handled can never be n, right? So the following ought to work: 255if

Re: Possible error in apr_rgetline_core

On Tue, Sep 21, 2004 at 11:33:32AM -0500, Rici Lake wrote: On 21-Sep-04, at 11:03 AM, Joe Orton wrote: pass 2: bytes_handled = 8191, *s = 8191-byte region Quite right: I hadn't looked closely enough at the case where there was no user-supplied buffer :( Between us we'll have it covered...

Re: cvs commit: httpd-2.0 configure.in

--On Monday, September 20, 2004 12:12 PM + [EMAIL PROTECTED] wrote: jorton 2004/09/20 05:12:01 Modified:.configure.in Log: * configure.in: Ensure that $CC and $CPP are correctly passed through to the pcre configure script if config caching is disabled (the autoconf

Re: cvs commit: httpd-2.0 configure.in

On Tue, Sep 21, 2004 at 12:28:52PM -0700, Justin Erenkrantz wrote: --On Monday, September 20, 2004 12:12 PM + [EMAIL PROTECTED] wrote: jorton 2004/09/20 05:12:01 Modified:.configure.in Log: * configure.in: Ensure that $CC and $CPP are correctly passed through

Add ETag to ap_scan_script_header_err_core()

Hello, I've been trying to find a solution to a problem that mod_cache has with handling Etag's properly. I'm working with Apache 2.0.51. Below is a diff to ./server/util_script.c that seems to fix the problem... 564a565,567 else if (!strcasecmp(w, ETag)) {

Rotatelogs crashes after fork() and execve() on Solaris/Intel

Hello, On Solaris/Intel, rotatelogs will always crash right after it is spawned. This only happens on the Solaris/Intel platform. It works fine on Solaris/SPARC, and on Linux, etc. But for some reason, the code that is currently used in Apache 2.0.51 to fork() and exec() processes like

Re: Add ETag to ap_scan_script_header_err_core()

--On Tuesday, September 21, 2004 3:48 PM -0700 Michael Corcoran [EMAIL PROTECTED] wrote: I've been trying to find a solution to a problem that mod_cache has with handling Etag's properly. I'm working with Apache 2.0.51. Below is a diff to ./server/util_script.c that seems to fix the problem...

Re: Rotatelogs crashes after fork() and execve() on Solaris/Intel

--On Tuesday, September 21, 2004 4:52 PM -0700 Michael Corcoran [EMAIL PROTECTED] wrote: On Solaris/Intel, rotatelogs will always crash right after it is spawned. This only happens on the Solaris/Intel platform. It works fine on Solaris/SPARC, and on Linux, etc. But for some reason, the code

Re: cvs commit: httpd-2.0 configure.in

--On Tuesday, September 21, 2004 9:05 PM +0100 Joe Orton [EMAIL PROTECTED] wrote: I think just testing for $cache_file = /dev/null is simplest. That still fixes my problem and seems to work OK with a cache file specified too. I've committed that, let's see what breaks now ;) Thanks!