On 5 Apr 2002 [EMAIL PROTECTED] wrote:
> brianp 02/04/04 23:44:15
>
> Modified:modules/filters mod_include.c
> Log:
> Fix for the boundary case in which each character of an SSI directive
> is in a separate bucket...the code in send_parsed_content() doesn't
Holy crap, that was f
On Thu, 4 Apr 2002, William A. Rowe, Jr. wrote:
> > This patch fixes a core dump that occurs in mod_include during tag parsing
> > if the starting sequence (
Hello,
This mod_dav patch has search_hook interface
and a basic search_method for supporting DASL(SEARCH method).
It was compiled and tested with Apache/2.0.35-dev in Linux 2.4.9(i686).
Index: fs/repos.c
===
RCS file: /home/cvspubl
This is another attempt at fixing mod_autoindex. This works for me on
my computer, and it explains the problem. I haven't been able to
actually reproduce the problem, but I have seen the symptoms. Can
somebody who can reproduce PLEASE test this on their setup. I am hoping
to setup a failure c
On Fri, 5 Apr 2002, Cliff Woolley wrote:
> > AddOutputFilter INCLUDES .shtml
> >
> >SetOutputFilter BUCKETEER
> >
>
> Hm... can't get that to work either. Still trying stuff... are we
> sure the Add/SetOutputFilter directives work right?
Sorry, nevermind. I didn't know you needed to
> On Thu, 4 Apr 2002, Brian Pane wrote:
>
> >Cliff Woolley said:
> >>
> >> Why doesn't this work?
> >>
> >>SetOutputFilter BUCKETEER;INCLUDES
> >>
> >>
> > That ought to work; I'm not sure why it doesn't
> >
> > What I've used in the past is:
> > AddOutputFilter INCLUDES .shtml
> >
> >
On Thu, 4 Apr 2002, Brian Pane wrote:
>Cliff Woolley said:
>>
>> Why doesn't this work?
>>
>>SetOutputFilter BUCKETEER;INCLUDES
>>
>>
> That ought to work; I'm not sure why it doesn't
>
> What I've used in the past is:
> AddOutputFilter INCLUDES .shtml
>
>SetOutputFilter BUCKETEER
>
> > The proxy should flush, because otherwise the data won't stream to
the
> > client.
>
> doesn't the core flush once it has max-something bytes or eos?
Only if the data makes it to the core_output_filter. :-)
> > The problem that I see, is that the proxy shouldn't be removing
> > the C-L fr
At 11:43 PM 4/4/2002, rbb wrote:
>The problem that I see, is that the proxy shouldn't be removing
>the C-L from the response that the origin server provided.
>
>If you can get a C-L by removing the flush bucket, then the C-L filter
>is the thing providing the header data. But, we have a C-L from
On Thu, 4 Apr 2002, Ryan Bloom wrote:
> The proxy should flush, because otherwise the data won't stream to the
> client.
doesn't the core flush once it has max-something bytes or eos?
> The problem that I see, is that the proxy shouldn't be removing
> the C-L from the response that the origin s
> mod_proxy does not send a Content-Length header, seems because of the
> flush bucket inserted by ap_proxy_http_process_response()
>
> if i break in ap_content_length_filter, when a request is handled by
> default_handler, brigade looks like so:
> (gdb) dump_brigade b
> dump of brigade 0x8235318
mod_proxy does not send a Content-Length header, seems because of the
flush bucket inserted by ap_proxy_http_process_response()
if i break in ap_content_length_filter, when a request is handled by
default_handler, brigade looks like so:
(gdb) dump_brigade b
dump of brigade 0x8235318
0: bucke
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > With all of the new config/proc_mutex/hints changes again, once you
> > have all beaten upon them, would someone care to summarize the
accepted
> > "safe" versions so I might tar .34 tommorow?
>
> I wonder about that tar :) 2.0.34 is no
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> At 08:31 PM 4/4/2002, you wrote:
> >"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> >
> > > With all of the new config/proc_mutex/hints changes again, once you
> > > have all beaten upon them, would someone care to summarize the accepted
>
At 03:19 PM 4/4/2002, you wrote:
>rederpj 02/04/04 13:19:32
>
> Modified:modules/filters mod_include.c
> Log:
> This patch fixes a core dump that occurs in mod_include during tag parsing
> if the starting sequence (
At 08:38 PM 4/4/2002, you wrote:
>dear RM, please consider bumping for .34, else users with the typical ssl
>proxy config:
>
> SSLProxyEngine On
> ProxyPass/ https://foo/
> ProxyPassReverse / https://foo/
>
>will get this ugly error message on every request:
>[error] mod_ssl: C
At 08:31 PM 4/4/2002, you wrote:
>"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > With all of the new config/proc_mutex/hints changes again, once you
> > have all beaten upon them, would someone care to summarize the accepted
> > "safe" versions so I might tar .34 tommorow?
>
>I wonder ab
dear RM, please consider bumping for .34, else users with the typical ssl
proxy config:
SSLProxyEngine On
ProxyPass/ https://foo/
ProxyPassReverse / https://foo/
will get this ugly error message on every request:
[error] mod_ssl: Certificate Verification: Error ...
even tho
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> With all of the new config/proc_mutex/hints changes again, once you
> have all beaten upon them, would someone care to summarize the accepted
> "safe" versions so I might tar .34 tommorow?
I wonder about that tar :) 2.0.34 is not worth using
I get that error on the next startup after an Apache crash. Then I
run ipcs to see what is left over:
$ ipcs
-- Shared Memory Segments
key shmid owner perms bytes nattchstatus
0x00280267 0 root 644 1048576 3
0x0105087a 119809trawic
On Thu, 4 Apr 2002, Pier Fumagalli wrote:
> What do your last lines of configure.in look like? And when you run
> "./configure. " what's the output of the last (let's say) 50 lines?
mkdir: cannot create directory `docs/conf': No such file or directory
creating docs/conf/httpd-std.conf
./con
The last several changes should resolve a series of fairly random segfaults
that have been observed at shutdown by Covalent's QA group [I was even
able to reproduce in 'console' mode.] Although I'd love another pair of eyes
on these latest changes, I'll include them in the .34 release so we don't
>jim 02/04/04 13:35:43
>
> Modified:.configure.in
> Log:
> Typo
>
> Revision ChangesPath
> 1.425 +1 -1 apr/configure.in
With all of the new config/proc_mutex/hints changes again, once you
have all beaten upon them, would someone care to summarize the a
Can you tell us what your ScoreBoardFile directive is set to, and what
the file permissions of that file are (if it exists) and of the parent
directory?
Also, what platform are you using?
Unless you have a third-party app that needs direct access to the
scoreboard file, you should be able to rem
That is a problem in the Apache server itself. There has been a lot of
change to the scoreboard stuff over the past week or so. I would guess that
you're running into a bug related to that work.
I've CC'd the httpd developers' list.
Cheers,
-g
On Wed, Apr 03, 2002 at 10:33:42PM -0800, Sung Kim
"Doug MacEachern" <[EMAIL PROTECTED]> wrote:
> nope, still isn't there.
>
> % uname -a
> Linux mako.covalent.net 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
>
> % autoconf --version
> Autoconf version 2.13
>
> % cat config.nice
>
> #! /bin/sh
> #
> # Created by configure
>
> CFLAGS=
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: 04 April 2002 20:38
> To: [EMAIL PROTECTED]
> Subject: Re: httpd.conf no longer installed
>
>
> nope, still isn't there.
>
> % uname -a
> Linux mako.covalent.net 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
>
> % autoconf --ver
nope, still isn't there.
% uname -a
Linux mako.covalent.net 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
% autoconf --version
Autoconf version 2.13
% cat config.nice
#! /bin/sh
#
# Created by configure
CFLAGS="-Wall -g"; export CFLAGS
"/home/dougm/apache/farm/src/httpd-2.0-cvs/configu
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: 04 April 2002 20:30
> On Thu, 4 Apr 2002, Pier Fumagalli wrote:
>
> > Did you run ./buildconf?
>
> yup, always. i probably just need blow away my cvs tree and start from
> scratch. has cured similar trouble in the past. i'll report
On Thu, 4 Apr 2002, Pier Fumagalli wrote:
> Did you run ./buildconf?
yup, always. i probably just need blow away my cvs tree and start from
scratch. has cured similar trouble in the past. i'll report back if the
problem is still there.
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: 04 April 2002 20:17
> with httpd-2.0-HEAD, installing into a directory where no conf/ already
> exists, no httpd.conf is installed, only:
> % ls -1 conf/
> highperformance.conf
> highperformance-std.conf
> httpd.conf.in
> httpd-std.conf.
Doug MacEachern <[EMAIL PROTECTED]> wrote:
> with httpd-2.0-HEAD, installing into a directory where no conf/ already
> exists, no httpd.conf is installed, only:
> % ls -1 conf/
> highperformance.conf
> highperformance-std.conf
> httpd.conf.in
> httpd-std.conf.in
> magic
> mime.types
> ssl.conf
>
with httpd-2.0-HEAD, installing into a directory where no conf/ already
exists, no httpd.conf is installed, only:
% ls -1 conf/
highperformance.conf
highperformance-std.conf
httpd.conf.in
httpd-std.conf.in
magic
mime.types
ssl.conf
ssl-std.conf
problem does not exist with the APACHE_2_0_34 tag.
On Wed, Apr 03, 2002 at 08:47:40AM -0500, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > trawick 02/04/03 05:45:58
> >
> > Modified:server/mpm/prefork prefork.c
> > Log:
> > prefork MPM: add -DFOREGROUND option to use when you want
> >the parent process to ru
At 03:10 AM 4/4/2002, you wrote:
>Question for you guys:
>
>I'm working on a module for 2.0, which generates content (with Tcl).
>In 1.3, prior to setting things in motion, I did a
>
>ap_chdir_file(r->filename);
>
>to have everything running in the right place. In 2.0, because of the
>threading,
[ please CC responses ]
Question for you guys:
I'm working on a module for 2.0, which generates content (with Tcl).
In 1.3, prior to setting things in motion, I did a
ap_chdir_file(r->filename);
to have everything running in the right place. In 2.0, because of the
threading, this doesn't str
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: 03 April 2002 17:57
> Finishing touches... Makefile.in (long forgotten)... BTW, ap_config_path.h
> doesn't exist in the source tree (I believe it's an old source file left
> there somehow?)...
>
> Attached is the full-complete patch (inst
37 matches
Mail list logo
