On Wed, Sep 18, 2002 at 07:47:14PM -0700, Greg Stein wrote:
> Okay... I've checked in the change. I'd suggest tossing 2.0.41 and roll this
> fix into a 2.0.42. (I'm not suggesting using HEAD for 2.0.42)
>
> Something like:
>
> $ cvs tag -r APACHE_2_0_41 APACHE_2_0_42 # copy the tag
> $ cvs tag
By the way, I love the idea of backporting the Apache 2.0
ForceLanguagePriority into Apache 1.3... This directive completely solves a
looot of problems I've been having with stupid non-standards-conformant IE
and content negotation. Many thanks to whoever posted the patch. If only
it were possi
I didn't even compile this baby, let alone test it, but I wanted to check with
everyone if I'm finally moving in the right direction with this.
Bojan
PS. This is along the lines of what Ryan suggested, or at least I hope it is ;-)
-
This mail sent
This patch moves all the DAV method registration into the mod_dav module
from the http core. I'd like to do this for a couple reasons:
1) It makes more sense to register these methods from the same module
they are used in.
2) Since Apache can only handle 62 registered methods, it doesn't ma
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2002/09/17 07:02:16 $]
Release:
2.0.42 : in development.
2.0.41 : rolled September 16, 2002.
2.0.40 : released August 9, 2002 as GA.
2.0.39 : released June 17, 2002 as GA.
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2002/09/18 15:36:26 $]
Release:
1.3.27-dev: In development. Jim proposes a t/r on or around
Sept 24.
1.3.26: Tagged June 18, 2002.
1.3.25: Tagged June 17, 2002. Not relea
On Wed, Sep 18, 2002 at 07:31:27PM -0700, Greg Stein wrote:
>...
> Oh... wait a sec. I was getting too complicated. Simply sending an OPTIONS
> request *with a body* to a location using mod_dav_fs as its provider will
> blow up at that point. Well, mod_dav_FOO that doesn't provide versioning
> sup
On Wed, Sep 18, 2002 at 07:37:55PM -0400, [EMAIL PROTECTED] wrote:
>...
> First, a stack trace:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 18642)]
> 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762
> 1762if ((err = (*v
Well, I found my problem... APPARENTLY, SVN doesn't like the worker MPM...
This is with Apache 2.0.41. I'm ccing httpd-dev in case it's an apache
problem and not a svn problem.
Note, even when I did an OPTIONS on /svn, it would freeze for a good 2 minutes
or so.
The backtrace I got when I
More details. YAY
First, a stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 18642)]
0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762
1762if ((err = (*vsn_hooks->get_option)(resource, elem,
&body))
(gdb) where
On Wed, Sep 18, 2002 at 06:49:48PM -0400, [EMAIL PROTECTED] wrote:
>
> I don't know if this is in .41 because I haven't had time to test it
> yet. But, HEAD of mod_dav has an annoying seg fault. Basically, if you
> send an OPTIONS request for a location that isn't configured for DAV, the
> modu
On Thu, 2002-09-19 at 09:07, [EMAIL PROTECTED] wrote:
> yep, requests are always logged in order.
Thanks. Back to the code :-)
Bojan
On 19 Sep 2002, Bojan Smojver wrote:
> On Thu, 2002-09-19 at 07:59, [EMAIL PROTECTED] wrote:
>
> > Great, now one more change. :-)
> >
> > Don't add the fields to the structure. The conn_Rec has a vector for
> > modules to add data to. Create a log_config structure, and add the fields
> > th
On Thu, 2002-09-19 at 07:59, [EMAIL PROTECTED] wrote:
> Great, now one more change. :-)
>
> Don't add the fields to the structure. The conn_Rec has a vector for
> modules to add data to. Create a log_config structure, and add the fields
> there. This allows the core structures to remain as t
I don't know if this is in .41 because I haven't had time to test it
yet. But, HEAD of mod_dav has an annoying seg fault. Basically, if you
send an OPTIONS request for a location that isn't configured for DAV, the
module seg faults. I have traced it far enough to know where it is
happening, bu
On 19 Sep 2002, Bojan Smojver wrote:
> On Thu, 2002-09-19 at 00:05, [EMAIL PROTECTED] wrote:
>
> > The easiest way, would be to put the filters in mod_log_config, and have
> > that module save the information in a connection_rec vector.
>
> OK, I think I roughly understand what is the plan:
>
On Wed, 18 Sep 2002, Doug MacEachern wrote:
> On Wed, 18 Sep 2002, Geoffrey Young wrote:
>
> > I think the attached patch behaves as suggested.
>
> perfectly, thanks.
with 5.8.0 that is. with 5.6.1, dies with:
Error in option spec: "verbose:1"
-
On Thu, 2002-09-19 at 00:05, [EMAIL PROTECTED] wrote:
> The easiest way, would be to put the filters in mod_log_config, and have
> that module save the information in a connection_rec vector.
OK, I think I roughly understand what is the plan:
- introduce c->bytes_in and c->bytes_out (c is conn_
On Wed, 18 Sep 2002, Geoffrey Young wrote:
> I think the attached patch behaves as suggested.
perfectly, thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
As a bit of background, I am incorporating a somewhat customized version
of Apache 2.0.x into a software product here. Our product installer allows
the user to specify an install-to directory. On foreign-language systems
(e.g. Japanese) this could be a directory name with multibyte characters in
i
On Wed, 18 Sep 2002, Bojan Smojver wrote:
> Quoting [EMAIL PROTECTED]:
>
> > The problem is that the filters aren't HTTP specific. If you make this
> > change, then the filters will be written to take advantage of the f->r
> > field in connection level filters. Since that field doesn't make se
Hi!
I'm new to the
Apache and don't find my way in the code.
I'm looking for the
methods Apache uses to handle many multiple parallel requests. Can you point me
in which module or file I should look for that?
TIA
Carmel
Magen
There is another possibility to fix this, and that's within the module
itself (I've tested it and it works):
--
static void logio_create_req(request_rec *r) {
ap_filter_t *f;
conn_rec *c = r->connection;
/* Tie connection filters with r
Hi,
for few days, i am stressing my apache 2.0.40 with reverse proxy with a
tools named Silkperformer.
i have a really strange error, coming up often on some basic requests:
the request is http://web2.test.com/manual/images/pixel.gif
[Wed Sep 18 12:24:04 2002] [error] SSL error on reading data
The WWW-Authenticate header is being dropped from responses sent by
mod_proxy in reverse proxy mode, when the original server's response
was chunked.
The problem appears to be in ap_http_header_filter() in
modules/http/http_protocol.c, where we have:
if (r->status == HTTP_NOT_MODIFIED) {
[Forwarded to dev@httpd as this would affect httpd aswell]
-Original Message-
From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
Sent: 18 September 2002 13:00
To: apr
Cc: Mladen Turk
Subject: pcre in aprutil
Hi,
We would like to use the pcre of httpd-2.0/srclib/pcre in mod_jk2 (Jakar
On Tue, Sep 17, 2002 at 06:43:41PM -, [EMAIL PROTECTED] wrote:
> striker 2002/09/17 11:43:41
>
> Modified:buildhttpd_roll_release
> Log:
> Fixup the timestamp on modules/ssl/ssl_expr_parse.c after running
> buildconf when we roll a release.
>
The same has to be done for
On Wed, 2002-09-18 at 19:24, Thom May wrote:
> Shared memory (as used by at least the ssl module) needs to rethink
> how they go about cleaning it up. Currently kill -9 the apache
> processes or it would appear that even /etc/init.d/apache2 reload will
> cause apache to fail to start because the
On Wed, Sep 18, 2002 at 10:24:43AM +0100, Thom May wrote:
>...
> please can the cc line ([EMAIL PROTECTED]) be maintained so the bug
> gets a record of this?
Well, dunno about that. Since this list obeys Ken's nefarious insistence on
Reply-To munging, who knows what'll happen when people reply?
I'm forwarding this debian bug onto the dev list for discussion and
comments.
please can the cc line ([EMAIL PROTECTED]) be maintained so the bug
gets a record of this?
Cheers,
-Thom
--
Thom May -> [EMAIL PROTECTED]
< robster> SHIT
< robster> woody doesnt support devfs
< willy> devfs is FUcking
30 matches
Mail list logo