Geoffrey Young wrote:
for the record, I just got this from a coredump when trying to use a module
with 2.1:
#0 0x00348a40 in mpxs_Apache2__RequestRec_content_type (my_perl=0x9d953d8,
r=0x9dfa310, type=0xa7c9c10)
at Apache2__RequestRec.h:27
27 MP_CGI_HEADER_PARSER_OFF(rcfg);
I
for the record, I just got this from a coredump when trying to use a module
with 2.1:
#0 0x00348a40 in mpxs_Apache2__RequestRec_content_type (my_perl=0x9d953d8,
r=0x9dfa310, type=0xa7c9c10)
at Apache2__RequestRec.h:27
27 MP_CGI_HEADER_PARSER_OFF(rcfg);
I think the "proble
Joe Orton wrote:
Hi folks, this fixes the build against the httpd trunk which renamed the
mis-named ap_http_method macro to ap_http_scheme:
Thanks Joe, comitted with a few tweaks as r124425. #ifdef of that sort
are usually stuffed in modperl_(apache|apr)_compat.(h|c)
---
124295)
+++ xs/Apache/RequestRec/Apache__RequestRec.h (working copy)
@@ -44,6 +44,11 @@
return retval;
}
+/* 2.1 renamed ap_http_method to the ap_http_scheme */
+#ifndef ap_http_scheme
+#define ap_http_scheme(r) ap_http_method(r)
+#endif
+
static MP_INLINE
int
n cycle" on marc's [EMAIL PROTECTED] archives
comes up empty.
I'm not sure really what you expect. That no API changes can be made
during 2.1 development unless they were predicted ahead of time by N
years and marked with a red dot?
I expect the API changes in the 2 adjucent major
dropped.
Heh, a search for "deprecation cycle" on marc's [EMAIL PROTECTED] archives
comes up empty.
I'm not sure really what you expect. That no API changes can be made
during 2.1 development unless they were predicted ahead of time by N
years and marked with a red dot?
same generation of the project can be dropped.
>>
>> Heh, a search for "deprecation cycle" on marc's [EMAIL PROTECTED] archives
>> comes up empty.
>
> I'm not sure really what you expect. That no API changes can be made
> during 2.1 development unless t
>>so, if I understand the debate, it's whether this ability should remain
>>solely with mod_proxy, or whether other modules should be allowed to decide
>>whether they should set 'ProxyRequest On' at runtime.
>>
>>is that right?
>
>
> Yup.
I guess I could go either way. part of me thinks that
rch for "deprecation cycle" on marc's [EMAIL PROTECTED] archives
> comes up empty.
I'm not sure really what you expect. That no API changes can be made
during 2.1 development unless they were predicted ahead of time by N
years and marked with a red dot?
2.2 will not be
On Wed, Dec 01, 2004 at 10:59:22AM -0500, Geoffrey Young wrote:
...
> now, I _think_ joes argument is that for the second part the server should
> be required to set 'ProxyRequest On' in httpd.conf, which indicates the
> arrangement the client and server have agreed upon.
Yes, that's an accurate s
>> Well, convince me that it's useful decide it dynamically. If the client
>> is not configured to use the server as a forward proxy, and the server
>> is not configured up-front to act as a forward proxy, when does it make
>> sense to treat a request as being "forward proxied"?
>> Whether or not
Stas Bekman <[EMAIL PROTECTED]> writes:
> One needs to go through a deprecation cycle before any backwards
> compatibility in the same generation of the project can be dropped.
Heh, a search for "deprecation cycle" on marc's [EMAIL PROTECTED] archives
comes up empty.
--
Joe Schaefer
--
Joe Orton wrote:
On Wed, Dec 01, 2004 at 09:40:54AM -0500, Stas Bekman wrote:
Joe Orton wrote:
On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
I can't recall whether this was discussed before, but t/modules/proxy.t
fails with httpd-2.1. Is anybody following the mod_proxy ch
On Wed, Dec 01, 2004 at 09:40:54AM -0500, Stas Bekman wrote:
> Joe Orton wrote:
> >On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
> >
> >>I can't recall whether this was discussed before, but t/modules/proxy.t
> >>fails with httpd-2.1. Is a
Joe Orton wrote:
On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
I can't recall whether this was discussed before, but t/modules/proxy.t
fails with httpd-2.1. Is anybody following the mod_proxy changes?
I'll note that this may get fixed such that it only works for enabling
On Fri, Nov 26, 2004 at 04:37:49PM -0500, Stas Bekman wrote:
> I can't recall whether this was discussed before, but t/modules/proxy.t
> fails with httpd-2.1. Is anybody following the mod_proxy changes?
I'll note that this may get fixed such that it only works for enabling
On Mon, Nov 29, 2004 at 09:30:24AM -0500, Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
> > I can't recall whether this was discussed before, but t/modules/proxy.t
> > fails with httpd-2.1. Is anybody following the mod_proxy changes?
>
> yes, joe orton and I
Stas Bekman wrote:
> I can't recall whether this was discussed before, but t/modules/proxy.t
> fails with httpd-2.1. Is anybody following the mod_proxy changes?
yes, joe orton and I have been following this. IIRC what happened is that
joe figured out the issue and placed it in 2.2 s
I can't recall whether this was discussed before, but t/modules/proxy.t
fails with httpd-2.1. Is anybody following the mod_proxy changes?
[Fri Nov 26 16:35:51 2004] [error] [client 127.0.0.1] File does not exist:
proxy:http://rabbit.stason.org:8531/TestModules__proxy
Joe Orton wrote:
> On Mon, Oct 11, 2004 at 09:26:37AM -0400, Geoffrey Young wrote:
>
>>Joe Orton wrote:
>>
>>>as far as the fact that mod_proxy in HEAD refuses to
>>>act as a forward proxy unless "ProxyRequests On" has been configured.
>>>So adding "ProxyRequests On" as below fixes the test but
On Mon, Oct 11, 2004 at 09:26:37AM -0400, Geoffrey Young wrote:
> Joe Orton wrote:
> > as far as the fact that mod_proxy in HEAD refuses to
> > act as a forward proxy unless "ProxyRequests On" has been configured.
> > So adding "ProxyRequests On" as below fixes the test but whether this
> > should
Joe Orton wrote:
> On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
>
>>hi all...
>>
>>just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
>>this afternoon trying to see what (of importance) has changed in between 2.0
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
> hi all...
>
> just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
> this afternoon trying to see what (of importance) has changed in between 2.0
> and HEAD but I can't see wher
Joe Orton wrote:
On Fri, Oct 08, 2004 at 10:27:23AM -0400, Stas Bekman wrote:
Joe Orton wrote:
On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
And it'd be nice for the failing test to run t/REPORT and include it in
the output. W/o it we know almost nothing about what perl and apache
On Fri, Oct 08, 2004 at 10:27:23AM -0400, Stas Bekman wrote:
> Joe Orton wrote:
> >On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
> >
> >>And it'd be nice for the failing test to run t/REPORT and include it in
> >>the output. W/o it we know almost nothing about what perl and apache
Joe Orton wrote:
On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
And it'd be nice for the failing test to run t/REPORT and include it in
the output. W/o it we know almost nothing about what perl and apache
builds were used.
I guessed you'd say that... I've changed the script to appe
On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
> And it'd be nice for the failing test to run t/REPORT and include it in
> the output. W/o it we know almost nothing about what perl and apache
> builds were used.
I guessed you'd say that... I've changed the script to append ./t/REPO
Joe Orton wrote:
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
hi all...
just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
this afternoon trying to see what (of importance) has changed in between 2.0
and HEAD but I can't see where it is at
ing to generate that?
for the curious, here's what I have been running nightly. current mod_perl
CVS against:
2.0.47-worker-perl-5.8.5
2.0.52-worker-perl-5.8.5
2.1-worker-perl-5.8.5
2.1-prefork-perl-5.8.5
2.1-prefork-perl-5.8.5-nothreads
2.0-worker-perl-5.8.0
2.0-worker-perl-5.8.5
2.0-prefo
On Thu, Oct 07, 2004 at 04:04:16PM -0400, Geoffrey Young wrote:
> hi all...
>
> just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
> this afternoon trying to see what (of importance) has changed in between 2.0
> and HEAD but I can't see wher
hi all...
just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time
this afternoon trying to see what (of importance) has changed in between 2.0
and HEAD but I can't see where it is at the moment.
so, if anyone has been following proxy development of late and know
ough this single change affected 2.1 in that GET and HEAD
requests can now be expected to behave exactly the same wrt the C-L header.
at least this is what our tests show - in 2.1 there is no difference at all
between the C-L header that GET and HEAD produce. overall a good thing, I'd
think.
the o
affected 2.1 in that GET and HEAD
requests can now be expected to behave exactly the same wrt the C-L header.
at least this is what our tests show - in 2.1 there is no difference at all
between the C-L header that GET and HEAD produce. overall a good thing, I'd
think.
the only thing that m
> I guess the solution is to build APR by itself, outside of httpd, and use
> that from now on
which does indeed work, so I guess this is all a non-issue.
good for the archives, anyway :)
other issues in another thread...
--Geoff
---
hi all...
I'm having a difficult time building mp2 against the release httpd 2.1
release candidate due to some chicken-and-egg type problems.
it looks like httpd 2.1 is going to be requiring an existing apr 1.0
installation, meaning that apr will no longer be distributed with httpd.
so,
Joe Orton wrote:
On Wed, Aug 25, 2004 at 09:31:27AM -0700, Stas Bekman wrote:
Joe Orton wrote:
The thing I really want is to fix out-of-tree apr-util builds anyway,
can someone commit that half of the patch if it's OK?
What problem does it solve? Is this something needed for httpd 2.1?
If
On Wed, Aug 25, 2004 at 09:31:27AM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> >The thing I really want is to fix out-of-tree apr-util builds anyway,
> >can someone commit that half of the patch if it's OK?
>
> What problem does it solve? Is this something needed fo
What problem does it solve? Is this something needed for httpd 2.1?
Index: Build.pm
===
RCS file: /home/cvspublic/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.171
diff -u -r1.171 Build.pm
--- Build.pm 22 Aug 2004 17:57:40 - 1
On Tue, Aug 24, 2004 at 11:52:15PM -0700, Stas Bekman wrote:
> but Joe, don't let this discussion get on your way, commit the thing
> (after the 2.0 way) and we will optimise it later.
But re-ordering the tests really defeats the point of the change (which
was to *skip* all the messy 2.0 tests an
Philippe M. Chiasson wrote:
[...]
No, I suggested to figure out whether we are running under 2.0 or 2.1
and then use the appropriate method, without trying both. e.g.:
if (httpd 2.0) {
# the current way
} else {
# 2.1 has apxs -q AP[RU]_CONFIG as the definitive location
rewritten to find out what syntax to use (2.0 or
2.1) once and not do that repeatedly? This function is the cause of the
slow configuration (too many shell calls), so trying to minimize it
will be a great thing.
Why "repeatedly"? Surely since the value is cached it's only done twic
syntax to use (2.0 or
2.1) once and not do that repeatedly? This function is the cause of the
slow configuration (too many shell calls), so trying to minimize it
will be a great thing.
Why "repeatedly"? Surely since the value is cached it's only done twice,
once for apr-config a
t;Thanks Joe.
> >>>
> >>>Any chance this can be rewritten to find out what syntax to use (2.0 or
> >>>2.1) once and not do that repeatedly? This function is the cause of the
> >>>slow configuration (too many shell calls), so trying to minimize i
Joe Orton wrote:
On Wed, Aug 18, 2004 at 07:55:25PM +0100, Joe Orton wrote:
On Wed, Aug 18, 2004 at 10:54:13AM -0700, Stas Bekman wrote:
Joe Orton wrote:
Thanks Joe.
Any chance this can be rewritten to find out what syntax to use (2.0 or
2.1) once and not do that repeatedly? This function is the
On Wed, Aug 18, 2004 at 07:55:25PM +0100, Joe Orton wrote:
> On Wed, Aug 18, 2004 at 10:54:13AM -0700, Stas Bekman wrote:
> > Joe Orton wrote:
> > Thanks Joe.
> >
> > Any chance this can be rewritten to find out what syntax to use (2.0 or
> > 2.1) once and not
On Wed, Aug 18, 2004 at 10:54:13AM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> Thanks Joe.
>
> Any chance this can be rewritten to find out what syntax to use (2.0 or
> 2.1) once and not do that repeatedly? This function is the cause of the
> slow configuration (too man
2004 12:48:12 -
@@ -976,6 +976,16 @@
$self->{$key} = $self->{$mp_key};
}
+# 2.1 has apxs -q AP[RU]_CONFIG as the definitive location
+my $apxs_key = uc($what) . "_CONFIG";
+if (!$self->{$key} && !$self->httpd_is_source_tree) {
+
4 12:48:12 -
@@ -976,6 +976,16 @@
$self->{$key} = $self->{$mp_key};
}
+# 2.1 has apxs -q AP[RU]_CONFIG as the definitive location
+my $apxs_key = uc($what) . "_CONFIG";
+if (!$self->{$key} && !$self->httpd_is_source_tree) {
+
Geoffrey Young wrote:
actually, what I would do is work around it for now then
wait
until we have something like APACHE1, APACHE2, and additional
breakdowns of
APACHE20, APACHE22, and Apache23 (or somesuch).
May be just comment out 'IdentityCheck On' with an explanation of why we
did so, until we
>> actually, what I would do is work around it for now then
>> wait
>> until we have something like APACHE1, APACHE2, and additional
>> breakdowns of
>> APACHE20, APACHE22, and Apache23 (or somesuch).
>
>
> May be just comment out 'IdentityCheck On' with an explanation of why we
> did so, until w
Geoffrey Young wrote:
On the perl level yes, but I'm not sure about the config, it should be
something like:
IdentityCheck On
IdentityCheck On
but I don't think we have that , Geoff?
no, not at the moment, but I think it's likely in order, especially with 2.2
on the way. actua
> On the perl level yes, but I'm not sure about the config, it should be
> something like:
>
>
>
> IdentityCheck On
>
>
>
> IdentityCheck On
>
>
> but I don't think we have that , Geoff?
no, not at the moment, but I think it's likely in order, especially with 2.2
on the
Ian Holsman wrote:
The IdentityCheck directive seems to have moved to mod_ident.c in apache
2.1
One of the access tests explitly uses this directive
Options None
Options Indexes FollowSymLinks
AuthName modperl
AuthType none
IdentityCheck On
SetHandler modperl
The IdentityCheck directive seems to have moved to mod_ident.c in apache 2.1
One of the access tests explitly uses this directive
Options None
Options Indexes FollowSymLinks
AuthName modperl
AuthType none
IdentityCheck On
SetHandler modperl
PerlResponseHandler TestAPI
Geoffrey Young wrote:
Are you sure that httpd_version_as_int is the right method to decide
which apr is used?
nope, and now that you mention it, it certainly assumes you got apr from httpd.
Is there a better way?
I can't think of one, but I obviously don't have my apr chops lately. but
you're
> Are you sure that httpd_version_as_int is the right method to decide
> which apr is used?
nope, and now that you mention it, it certainly assumes you got apr from httpd.
> Is there a better way?
I can't think of one, but I obviously don't have my apr chops lately. but
you're right, we shoul
Geoffrey Young wrote:
Joe Schaefer wrote:
Geoffrey Young <[EMAIL PROTECTED]> writes:
hi...
the mod_perl tests currently dump core dump with httpd 2.1/APR 1.0. I spent
the better part of the morning trying to figure out why, but I can't quite
see it.
Err, apxs was recently patched to
Joe Schaefer wrote:
> Geoffrey Young <[EMAIL PROTECTED]> writes:
>
>
>>hi...
>>
>>the mod_perl tests currently dump core dump with httpd 2.1/APR 1.0. I spent
>>the better part of the morning trying to figure out why, but I can't quite
>>see
Geoffrey Young <[EMAIL PROTECTED]> writes:
> hi...
>
> the mod_perl tests currently dump core dump with httpd 2.1/APR 1.0. I spent
> the better part of the morning trying to figure out why, but I can't quite
> see it.
Err, apxs was recently patched to use(supply
hi...
the mod_perl tests currently dump core dump with httpd 2.1/APR 1.0. I spent
the better part of the morning trying to figure out why, but I can't quite
see it.
the first failing test is t/apr-ext/bucket.t which gives the below output.
the core dump yields nothing useful (just a bun
On Wednesday 28 April 2004 02:09 am, Geoffrey Young wrote:
> >>>>It looks like 2.1 is going through a big update tonight,
> >>>>and the cvs sources are unstable.
> >>>>
> >>>>If you have a chance, can you let me know when it is
> >&
>>>>It looks like 2.1 is going through a big update tonight,
>>>>and the cvs sources are unstable.
>>>>
>>>>If you have a chance, can you let me know when it is
>>>>usable again?
my nightly build last night went off without a hitch:
On Monday 26 April 2004 04:17 am, Geoffrey Young wrote:
> CCing to the dev list :)
>
> Beau E. Cox wrote:
> > On Monday 26 April 2004 03:43 am, you wrote:
> >>Beau E. Cox wrote:
> >>>Hi -
> >>>
> >>>It looks like 2.1 is going through
CCing to the dev list :)
Beau E. Cox wrote:
> On Monday 26 April 2004 03:43 am, you wrote:
>
>>Beau E. Cox wrote:
>>
>>>Hi -
>>>
>>>It looks like 2.1 is going through a big update tonight,
>>>and the cvs sources are unstable.
>>>
&g
In article <[EMAIL PROTECTED]>, Stas Bekman <[EMAIL PROTECTED]>
wrote:
> Ian Holsman wrote:
> > -8<-- Start Bug Report 8<--
> > 1. Problem Description:
> >
> > Failed 2/2 tests, 0.00% okay
> > Failed TestStat Wstat Total Fail Failed
Ian Holsman wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
httpd-2.1/darwin test failures.
(same results regardless of which perl version (5.6.1/5.8.3) I used)
t/modules/cgiupload.1..2
# Running under perl version 5.008003 for
Ian Holsman wrote:
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
>
> httpd-2.1/darwin test failures.
> (same results regardless of which perl version (5.6.1/5.8.3) I used)
hmm. while I don't use darwin, I don
-8<-- Start Bug Report 8<--
1. Problem Description:
httpd-2.1/darwin test failures.
(same results regardless of which perl version (5.6.1/5.8.3) I used)
2. Used Components and their Configuration:
*** mod_perl version 1.9911
*** using lib/
68 matches
Mail list logo
