flood STATUS: -*-text-*-
Last modified at [$Date: 2002/01/17 01:09:45 $]
Release:
milestone-04: In development
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
milestone-02: Tagged August 13, 2001
On Thu, Mar 07, 2002 at 09:27:17AM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/03/07 01:27:17
Modified:include ap_mmn.h util_filter.h
modules/experimental mod_cache.c mod_case_filter.c
mod_case_filter_in.c mod_charset_lite.c
On Wed, Mar 06, 2002 at 04:17:58PM -0800, Doug MacEachern wrote:
to those working on filters, please make sure httpd-test/perl-framework
tests are passing. i'm seeing a bunch fail at the moment, a couple with
response had protocol HTTP/0.9 (headers not sent?) and various
segvs:
I think
Jeff Trawick wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Yep... Looks like it's no problem with 2.52.
Anyone have hearburn if I adjust buildcheck.sh to make 2.52 the
new requirement?
at least a little, but I'm not exactly sure how much :) In the 2.0.30
timeframe a colleage
Aaron Bannert wrote:
The fix to this is to add a AllowProxy directive to the options
directive.
Unfortunately, I think we've run out of bits in there...
Then we need more bits!!! :)
Regards,
Graham
--
-
[EMAIL PROTECTED]There's a
This fixes PR10067. However, this is a fix for the symptom rather than the
cause, I think. Fundamentally, going into a system's htdocs dir and blowing
away anything called CVS is a big mistake. It doesn't make allowances for
all number of things, including the fact that the domains the server is
Cliff Woolley [EMAIL PROTECTED] writes:
On Fri, 1 Mar 2002, Cliff Woolley wrote:
Does this look right? (attached to avoid line wrapping)
Hmm, no, it doesn't. :-/ Scratch that. Back to the drawing board.
What was wrong with it?
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at
With the current HEAD (configured using --prefix=/Apps/apache2), I get the
following in my ap_config_auto.h:
/* Location of the config file, relative to the Apache root directory */
#define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf
whereas in, say, 2.0.32 it reads:
/* Location of the
* Brian Havard ([EMAIL PROTECTED]) wrote :
With the current HEAD (configured using --prefix=/Apps/apache2), I get the
following in my ap_config_auto.h:
/* Location of the config file, relative to the Apache root directory */
#define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf
From: Brian Havard [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 14:20
With the current HEAD (configured using --prefix=/Apps/apache2), I get the
following in my ap_config_auto.h:
/* Location of the config file, relative to the Apache root directory */
#define SERVER_CONFIG_FILE
Hi,
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3503)]
0x402e24b3 in strncmp (s1=0x0, s2=0x403fc7c8 text/html, n=9) at
../sysdeps/generic/strncmp.c:42
42c1 = (unsigned char) *s1++;
(gdb) bt
#0 0x402e24b3 in strncmp (s1=0x0, s2=0x403fc7c8
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 13:56
Hi,
[...]
Can someone tell me if r-content_type is always supposed
to be pointing to something?
Nevermind, I figured it out by looking at the other modules
who test r-content_type.
Fix committed.
Thanks,
On Wed, 6 Mar 2002, Graham Leggett wrote:
mod_accel is not proxy. It's accelarator. It can not work as usual proxy.
I did not even try to implement it - Apache 1.3 is poor proxy. Squid or
Oops are much better.
Until recently you were not aware that the proxy had been updated - I
would
Ryan Bloom [EMAIL PROTECTED] writes:
But I guess the problem is a misuse of r-proto_input_filters
vs. r-input_filters on this path???
Nope. This problem is in the proxy itself.
That's what I meant... I had tried half of your fix with no luck (and
worse, no understanding :) ).
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote :
aaron 02/03/07 06:26:07
Modified:.config.layout
Log:
Add a missing errordir entry in the Debian config.layout.
PR: 10067
Obtained from: Dirk-Jan Faber [EMAIL PROTECTED]
Unfortunately that fix isn't quite
On Wed, Mar 06, 2002 at 04:17:58PM -0800, Doug MacEachern wrote:
to those working on filters, please make sure
httpd-test/perl-framework
tests are passing. i'm seeing a bunch fail at the moment, a couple
with
response had protocol HTTP/0.9 (headers not sent?) and various
segvs:
I
* Brian Havard ([EMAIL PROTECTED]) wrote :
With the current HEAD (configured using --prefix=/Apps/apache2), I
get
the
following in my ap_config_auto.h:
/* Location of the config file, relative to the Apache root
directory */
#define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf
Ryan Bloom [EMAIL PROTECTED] writes:
But I guess the problem is a misuse of r-proto_input_filters
vs. r-input_filters on this path???
Nope. This problem is in the proxy itself.
That's what I meant... I had tried half of your fix with no luck (and
worse, no understanding :) ).
On Wed, Mar 06, 2002 at 11:42:11PM -0800, Greg Stein wrote:
apr_bucket_read(NONBLOCK)
if (got_nothing)
do_some_work
flush_some_buffers
apr_bucket_read(BLOCK)
process_buckets()
In other words, you could see if you have some work to do. If not, then you
go off and flush out other
On Wed, Mar 06, 2002 at 11:42:11PM -0800, Greg Stein wrote:
apr_bucket_read(NONBLOCK)
if (got_nothing)
do_some_work
flush_some_buffers
apr_bucket_read(BLOCK)
process_buckets()
In other words, you could see if you have some work to do. If not,
then
you
go off and flush
* Ryan Bloom ([EMAIL PROTECTED]) wrote :
* Brian Havard ([EMAIL PROTECTED]) wrote :
it's not finished yet :)
use -d /path -f /path/to/conf/file
That's not good enough Thom. The -d must be able to work on its own.
That's why we allow relative paths for just about everything.
I
On Thu, Mar 07, 2002 at 11:30:05AM +, Thom May wrote:
This fixes PR10067. However, this is a fix for the symptom rather than the
cause, I think. Fundamentally, going into a system's htdocs dir and blowing
away anything called CVS is a big mistake. It doesn't make allowances for
all
On Thu, Mar 07, 2002 at 01:37:28PM +0100, Sander Striker wrote:
I know this stuff's been hacked at recently, I just want to let people know
it's not finished yet :)
Yes, that was me. :)
configure.in, lines 446-448:
APR_EXPAND_VAR(ap_sysconfdir, $sysconfdir)
* Thom May ([EMAIL PROTECTED]) wrote :
* Ryan Bloom ([EMAIL PROTECTED]) wrote :
* Brian Havard ([EMAIL PROTECTED]) wrote :
it's not finished yet :)
use -d /path -f /path/to/conf/file
That's not good enough Thom. The -d must be able to work on its own.
That's why we allow
On Thu, Mar 07, 2002 at 03:38:59PM +, Thom May wrote:
By way of replying to myself, here's the patches.
It creates a new macro in ac_common.m4 in apr, APR_STRIP_PREFIX, and uses
that to generate a relative path.
This is integrated into confgure.in to give a relative path for
On Thu, 7 Mar 2002, Graham Leggett wrote:
Aaron Bannert wrote:
The fix to this is to add a AllowProxy directive to the options
directive.
Unfortunately, I think we've run out of bits in there...
Then we need more bits!!! :)
Yes, we could add more bits in 2.0. But my question
Aaron Bannert wrote:
If nobody gets to it first, I'll create another m4 macro for striping
off $prefix from $var. If $prefix isn't a prefix on $var then it won't
change $var.
perhaps APR_UNPREPEND_VAR(var, $prefix) ?
APR_STRIP_PREFIX_VAR ? :)
--
On Thu, Mar 07, 2002 at 10:57:21AM -0500, Joshua Slive wrote:
Yes, we could add more bits in 2.0. But my question remains the same as
it always has been: What is the advantage of adding something to Options
rather than having an independent directive?
The disadvantage is that nobody
Aaron Bannert wrote:
+1 on adding new directives and not extending Options, especially since
this directive only relates to mod_proxy.
+1 as well
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|]
* Aaron Bannert ([EMAIL PROTECTED]) wrote :
On Thu, Mar 07, 2002 at 03:38:59PM +, Thom May wrote:
I was thinking something more generic:
dnl APR_UNPREPEND_VAR(var, $to_strip)
dnl
AC_DEFUN(APR_UNPREPEND_VAR(,[
orig=$$1
to_strip=$2
rel=`echo $orig|sed -e s#^${to_strip}##`
$1=$rel
I am working on a project to write an apache module in C++. Do I need
anything else other than wrapping MODULE_VAR_EXPORT in extern C{}?
Thanks!
--
Wei Weng
Network Software Engineer
KenCast Inc.
On Thu, Mar 07, 2002 at 12:06:04PM -0500, Wei Weng wrote:
I am working on a project to write an apache module in C++. Do I need
anything else other than wrapping MODULE_VAR_EXPORT in extern C{}?
This is the server development list. Your question would be better
asked on the module authors
On Thu, Mar 07, 2002 at 09:42:36AM -0800, Aaron Bannert wrote:
This is the server development list. Your question would be better
asked on the module authors mailing list ([EMAIL PROTECTED]).
Send a message to [EMAIL PROTECTED] to subscribe.
Oop, looks like you already made it over there.
server/config.c:396
return !!(cmd-limited (AP_METHOD_BIT methnum));
^^
Is that a typo or intentional?
It's intentional. This line always sparks a VERY large debate. The
reason for it is that it is the only way to ensure that you have a 1 or
0 result. By negating twice,
From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 19:58
server/config.c:396
return !!(cmd-limited (AP_METHOD_BIT methnum));
^^
Is that a typo or intentional?
It's intentional. This line always sparks a VERY large debate.
Then why didn't any one leave a
On Thu, 7 Mar 2002, Wei Weng wrote:
I am working on a project to write an apache module in C++. Do I need
anything else other than wrapping MODULE_VAR_EXPORT in extern C{}?
Thanks!
I have been working on an Apache-2.0 project which allows you to implement
modules in C++ without any of
Hi,
Should we bump the copyright year on all the files?
Anyone have a script handy?
Sander
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 20:48
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize that
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /*
Don't
use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize that comment
existed. If nobody is using that function, remove it.
Okay,
[EMAIL PROTECTED] wrote:
minfrin 02/02/20 22:03:09
Log:
When proxy enabled a slow frontend client to read from an
expensive backend server, it would wait until it had delivered
the response to the slow frontend client completely before
closing the backend
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 20:48
server/core.c:691
/* Should probably just get rid of this... the only code that cares is
* part of the core anyway (and in fact, it isn't publicised to other
* modules).
*/
Read the comment.
From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 20:49
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /*
Don't
use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize
On Thu, Mar 07, 2002 at 09:23:02PM +0100, Sander Striker wrote:
...
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /*
Don't
use this! */
If we shouldn't use it, why is it still here?
...
Having looked at the code now. MO is, yes they are
mod_disk_cache.c: In function `remove_entity':
mod_disk_cache.c:436: warning: unused variable `obj'
mod_disk_cache.c: In function `write_body':
mod_disk_cache.c:599: warning: unused variable `info'
mod_disk_cache.c: In function `set_cache_gcint':
mod_disk_cache.c:666: warning: unused variable
I just checked in some changes to mod_mem_cache, so hopefully those warning go away
now...
Bill
- Original Message -
From: Cliff Woolley [EMAIL PROTECTED]
To: Bill Stoddard [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, March 07, 2002 5:37 PM
Subject: warnings, fyi
On Thu, Mar 07, 2002 at 10:08:46PM -, [EMAIL PROTECTED] wrote:
gregames02/03/07 14:08:46
Modified:include http_protocol.h
server protocol.c
Log:
ap_rgetline: fix folding and partial line handling on ebcdic boxes. The
normal case worked OK, but due to
On Thu, 7 Mar 2002, Bill Stoddard wrote:
I just checked in some changes to mod_mem_cache, so hopefully those
warning go away now...
I'll double check, but the commit looked right on target. Thanks!
--Cliff
--
Cliff Woolley
Glibc 2.2.5 was compiled with gcc3. This is supposed to be allowable
with glibc 2.2.5, since it was unsupported prior. Does anyone know of
any issues doing this?
My binaries are portable, and that doesn't seem to be a problem. I'm
trying to gather information as I continue to try to chase down
On Thu, 7 Mar 2002, Jerry Baker wrote:
Apache 2.0.34-dev pulled from CVS today is sending text/plain as the
content-type on 404 responses. See example below:
HTTP/1.1 404 Not Found
Date: Thu, 07 Mar 2002 21:23:10 GMT
Server: Apache/2.0.34-dev (Win32)
Vary: accept-language
On Thu, Mar 07, 2002 at 05:43:20PM -0800, John Sterling wrote:
I think this is a general problem with get_canned_error_string - something
like the following should fix that
Index: modules/http/http_protocol.c
===
RCS file:
[EMAIL PROTECTED] wrote:
I think this is a general problem with get_canned_error_string - something
like the following should fix that
This patch does not appear to remedy the problem here on Win32.
--
Jerry Baker
[EMAIL PROTECTED] wrote:
I think this is a general problem with get_canned_error_string - something
like the following should fix that
Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file
correctly which explicitly states that it should be text/html?
--
Jerry Baker
On Thu, 7 Mar 2002, Jerry Baker wrote:
Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file
correctly which explicitly states that it should be text/html?
is it showing the content from that var file? what is the content you are
seeing (the plain html).
sterling
[EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002, Jerry Baker wrote:
Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file
correctly which explicitly states that it should be text/html?
is it showing the content from that var file? what is the content you are
seeing
On Thu, Mar 07, 2002 at 02:25:56PM -0800, Greg Stein wrote:
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r)
If we shouldn't use it, why is it still here?
So the /* don't use this! */ comment should go?
I would say rewrite it to be something like:
Modules
On Thu, 7 Mar 2002, Jerry Baker wrote:
[EMAIL PROTECTED] wrote:
On Thu, 7 Mar 2002, Jerry Baker wrote:
Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file
correctly which explicitly states that it should be text/html?
is it showing the content from that
On Thu, Mar 07, 2002 at 05:52:15PM -0600, Austin Gonyou wrote:
Glibc 2.2.5 was compiled with gcc3. This is supposed to be allowable
with glibc 2.2.5, since it was unsupported prior. Does anyone know of
any issues doing this?
I think you need the latest gcc version (3.0.4?) to compile glibc
57 matches
Mail list logo
