Hello all,
We currently are using Apache on our NetWare 5.1/6.0 servers and we are very
satisfied with it.
It have performance, stability and scability, just like NetWare. It's the
perfect marriage.
The only problem is about the logs, which can grow up until the
web-servers are restarted.
It seems as if the cookie-merging code in proxy_httpd.c version=1.83
introduced a new bug.
In one special case a single valued cookie is splitted into
two cookies with garbage values (see below)
In this text I added a newline after each attribute-value-pair,
just in case the mailprogram wrappes
Forwarded message:
==
Guenter, please forward this on to Brad at Novell and whoever else
needs to get a copy of it
Apache should definitely rotate the logs This feature is already
built in to other web server products (Novell Web Server 31, a
discontinued
A default install of
httpd-2.0_20020301051226.tar.gz
with configure
./configure --prefix=/usr/home/install/apache/2.0.32 --with-mpm=prefork
--enable-so --with-port=9595
cd /usr/home/install/apache/2.0.32/sbin
./apachectl start
Syntax error in httpd.conf
DocumentRoot must exist.
Heres are the
Hello!
We have been looking forward to v1324 since we have huge problems with
hanging threads with apache 1323 under heavy load and large POSTs from the
clients Is this beeing fixed? I haven't seen anything about it!
This bug has been reported by others also:
Jeff Trawick wrote:
Aaron Bannert [EMAIL PROTECTED] writes:
Could this be what's causing the SIGBUS? My current theory is that
there's a size mismatch betwen ws-conn_bytes (an apr_off_t) and
the (unsigned long) that only shows up on word-alignment-picky
chips like sparcs.
I'm bombing today on
Jeff Trawick [EMAIL PROTECTED] writes:
Aaron Bannert [EMAIL PROTECTED] writes:
Could this be what's causing the SIGBUS? My current theory is that
there's a size mismatch betwen ws-conn_bytes (an apr_off_t) and
the (unsigned long) that only shows up on word-alignment-picky
chips like
Jeff Trawick [EMAIL PROTECTED] writes:
This patch gets me running again:
Index: srclib/apr/shmem/unix/shm.c
===
RCS file: /home/cvs/apr/shmem/unix/shm.c,v
retrieving revision 1.14
diff -u -r1.14 shm.c
---
I've still got sleep in my eyes, so I might not be seeing this correctly
yet, but isn't the problem not that the segment itself is misaligned,
but that the structure that is being placed over that segment not
properly padded to account for alignment?
This looks like the problem to me:
At 17:57 24/02/2002 -0500, Victor J Orlikowski wrote:
On Sunday, 24 Feb 2002, at 22:54:22,
Christian Gross wrote:
Hi
I am running LINUX PPC (Yellow dog linux 21) I have done a latest
update
from the CVS database and I am trying to build APR
I keep getting the error with respect to
Aaron Bannert [EMAIL PROTECTED] writes:
I've still got sleep in my eyes, so I might not be seeing this correctly
yet, but isn't the problem not that the segment itself is misaligned,
but that the structure that is being placed over that segment not
properly padded to account for alignment?
Sorry this is late - I lost the original email
I think reverse proxy is usable all the time - mod_rewrite uses it by
generating an internal request And you can put rewrite+reverse proxy
rules (possibly using [P] flag) into htaccess
It's also conceptually less confusing to see adjacent default
On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote:
I'll punt for the moment on whether or not that code is bad The
shared memory code definitely needs to be fixed Look at this simple
test of alignment:
#include stddefh
#include stdioh
int main(void)
{
struct s1 {
Aaron Bannert [EMAIL PROTECTED] writes:
On Fri, Mar 01, 2002 at 12:34:49PM -0500, Jeff Trawick wrote:
printf(%d %d %d %d\n,
offsetof(struct s1,b),
offsetof(struct s2,b),
offsetof(struct s3,b),
offsetof(struct s4,b));
s3 =
Cliff Woolley [EMAIL PROTECTED] writes:
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Yes, I completely agree that each structure needs to be 64-bit aligned.
I don't see how the shared memory code itself is incorrect. It must be
mapping the segment at a properly aligned boundary, so as long
On Fri, Mar 01, 2002 at 01:37:27PM -0500, Jeff Trawick wrote:
Yes, I completely agree that each structure needs to be 64-bit aligned
I don't see how the shared memory code itself is incorrect
It is incorrect because it is returning addresses that aren't 64-bit
aligned
This code is in
On 1 Mar 2002, Jeff Trawick wrote:
Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns
addresses which aren't 64-bit aligned. That is broken. End of story.
Yeah, your last message cleared a lot up. Thanks. But I believe we're
all right. Both things are broken. :)
--Cliff
Cliff Woolley [EMAIL PROTECTED] writes:
On 1 Mar 2002, Jeff Trawick wrote:
Jeff calling Cliff and Aaron: apr_shm_baseaddr_get() returns
addresses which aren't 64-bit aligned. That is broken. End of story.
Yeah, your last message cleared a lot up. Thanks. But I believe we're
all
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Can we put that alignment macro in a common place in APR, since it
is not useful to apps and internals?
s/not/now/, right? :)
Does this look right? (attached to avoid line wrapping)
--
Cliff Woolley [EMAIL PROTECTED] writes:
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Can we put that alignment macro in a common place in APR, since it
is not useful to apps and internals?
but where :) apr_lib.h? (duck)
Does this look right? (attached to avoid line wrapping)
that is how
Looks like this code was removed in August. Without it the FancyIndexing
is never
done in the following example:
Directory ~ ^/abc/(a-z){5}
IndexOptions FancyIndexing
/Directory
===
--- core.c.oldFri Mar 1 12:53:09 2002
+++
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick
Sent: 01 March 2002 20:08
Cliff Woolley [EMAIL PROTECTED] writes:
On Fri, 1 Mar 2002, Aaron Bannert wrote:
Can we put that alignment macro in a common place in APR, since it
is not useful to apps and internals?
but where :)
Hi,
I am not sure whether it is because Mac OS X has changed in
later versions, but the attached patch turns of the
use of hsregex.
That will stop all the following warnins when Apache version 1.3.23
is used striaght from the box:
../include/hsregex.h:22: warning: redefinition of macro
I believe the attached .patch file should resolve our issues with the
subrequest
negotiation. Essentially, we want the sub request to build a new filter
chain if
we plan on using the subrequest as a 'fast internal redirect'.
This patch does just that, when we fast redirect, we replace the
Not that usually I send something worthwhile, but I don't like the default
Apache 20 layout :)
This fixes a couple of silly scripts
Pier
cvs server: Diffing
Index: apachectlin
===
RCS file:
Pier Fumagalli [EMAIL PROTECTED] wrote:
Not that usually I send something worthwhile, but I don't like the default
Apache 2.0 layout... :)
This fixes a couple of silly scripts...
Yeah... Really stupid... Forget it... (darn autoconf!)
Pier
On Fri, Mar 01, 2002 at 03:12:27PM -0600, William A Rowe, Jr wrote:
I believe the attached patch file should resolve our issues with the
subrequest
negotiation Essentially, we want the sub request to build a new filter
chain if
we plan on using the subrequest as a 'fast internal redirect'
Right then So after a fair amount of discussion on IRC, this is hopefully
the solution to all the configuration issues people have been hitting
The only issue now is that this code is distributed as part of the data
part of autoconf The license for autoconf _appears_ to say that the data
section
On Fri, Mar 01, 2002 at 03:12:27PM -0600, William A Rowe, Jr wrote:
I believe the attached patch file should resolve our issues with
the
subrequest
negotiation Essentially, we want the sub request to build a new
filter
chain if
we plan on using the subrequest as a 'fast internal
On Fri, Mar 01, 2002 at 04:50:16PM -0800, Ryan Bloom wrote:
I don't understand how this is working The original code from Will
came from a discussion that he and I had over the phone My question is
how were the protocol specific filters removed in this case?
Oh, damn, the problem is that
On Fri, Mar 01, 2002 at 09:15:46PM -0800, Ryan Bloom wrote:
You are thinking of this wrong Filters that are stored on
r-protocol_filters wouldn't survive a single request, they would be
required for the lifetime of the request The idea is that anything
that lives in r-output_filters would
On Fri, Mar 01, 2002 at 09:15:46PM -0800, Ryan Bloom wrote:
You are thinking of this wrong Filters that are stored on
r-protocol_filters wouldn't survive a single request, they would be
required for the lifetime of the request The idea is that anything
that lives in r-output_filters
32 matches
Mail list logo
