Re: cvs commit: modperl-2.0 Changes
+package Apache::Connection;
+
+# auth_type and user records don't exist in 2.0 conn_rec struct
+# 'PerlOptions +GlobalRequest' is required
+sub auth_type { Apache-request-auth_type }
+sub user { Apache-request-user }
+
1;
__END__
I think this may need a bit more thought (or at least more explanation).
in 1.0 there is both $r-auth_type and $c-auth_type, and they have
different meanings.
$r-auth_type represents the AuthType from the config (via
r-per_dir_config). when you get $r-auth_type, you're asking what kind of
authentication is configured for the request.
$c-auth_type is populated by authen handlers, after the user has been
authenticated, with whatever authentication method was used. I'm not sure
about the history of this, but I suppose in theory it is possible for a
client to request Digest auth, but the server fall back to Basic.
at any rate, I don't know how the current 2.0 or 2.1 aaa stuff handles this
difference, if at all, but we (well, I :) need to be clear on how that works
before agreeing that $r-connection-auth_type in Apache::Compat is the same
as $r-auth_type.
--Geoff
Re: cvs commit: modperl/t/net/perl util.pl
Doug MacEachern wrote: i had a bad feeling about this. we should not be implementing escape_html to begin with, the functionality should all be in apache. i'm going to back out the patch. sounds wise, especially considering people like Eric will end up with larger pages as a result, while the patch fixes a rather obscure vunerability, for which other solutions (HTML::Entities) are available. anybody care to make a doc patch to explain the problems with escape_html before the patch went in? I nominate robin, since I forget how it came up in the first place :) IIRC is was due to this post http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg00750.html and specifically an exploit involving browsers incorrectly assuming 0x8b as a and 0x9b as a , thus creating a way around escape_html(). Robin, does that accurately summarize it? it's been far too long for me :) --Geoff
RE: cvs commit: modperl/eg README httpd.conf.pl perl_sections.txt perl_sections_2.txt perlio.pl registry.pl startup.pl test.pl
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 02, 2002 12:38 AM To: [EMAIL PROTECTED] Subject: cvs commit: modperl/eg README httpd.conf.pl perl_sections.txt perl_sections_2.txt perlio.pl registry.pl startup.pl test.pl ask 02/03/01 21:38:22 Modified:eg README Removed: eg httpd.conf.pl perl_sections.txt perl_sections_2.txt perlio.pl registry.pl startup.pl test.pl Log: remove obsolete exampels we both forgot to update the MANIFEST for the stuff we removed: Warning: the following files are missing in your kit: ToDo eg/httpd.conf.pl eg/perl_sections.txt eg/registry.pl eg/startup.pl eg/test.pl Please inform the author. I'd take care of it, but I didn't see a commit email come through for the addition of the STATUS file, even though I got the mailing commit message... message from log_accum.pl, so maybe something is up with my access yet... --Geoff
RE: cvs commit: modperl Changes
-Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 7/6/01 4:33 PM Subject: cvs commit: modperl Changes dougm 01/07/06 13:33:46 Modified:src/modules/perl Apache.xs t/docs startup.pl .Changes Log: add Apache::add_version_component() function hmph... I can't get this to work at all. I read over Doug's original email and it's not what I am finding... a verbose test shows that the test suite is able to set things properly, though so something is going right somewhere, just not for me. maybe this is dependent upon the placement of modules, PerlRequire, etc? --Geoff
RE: cvs commit: modperl/Apache Apache.pm
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 1:31 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: modperl/Apache Apache.pm
dougm 01/04/25 22:30:46
Modified:.Changes
Apache Apache.pm
Log:
fix double-loading bug of Perl{Require,Module}s at startup time
hmmm... has anyone else noticed some strange behavior here? it seems that
since this patch went in I can't use startup.pl
to preload my modules in such a way that my custom directives get seen as
well...
I mean, that I used to use just
use Apache::Dispatch;
in a startup.pl and my custom directives would work just fine.
now, I get errors unless I use
PerlModule Apache::Dispatch
maybe I was taking advantage of a feature I shouldn't have been using?
--Geoff
RE: cvs commit: modperl/src/modules/perl mod_perl.h perl_config.c
pardon my being away, but does this mean that the earlier (possible) fix
Apache::ModuleConfig-get($r, __PACKAGE__)
was not the cause of the error, or that it was and the __PACKAGE__ part is
not necessary now?
I was wondering whether to fix my calls for people who weren't up to cvs
speed...
--Geoff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 22, 2000 2:52 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: modperl/src/modules/perl mod_perl.h perl_config.c
dougm 00/09/22 11:52:04
Modified:.Changes
src/modules/perl mod_perl.h perl_config.c
Log:
plug leak in DIR_MERGE
rename mod_perl_cleanup_av - mod_perl_cleanup_sv
Revision ChangesPath
1.517 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.516
retrieving revision 1.517
diff -u -r1.516 -r1.517
--- Changes 2000/09/13 07:48:55 1.516
+++ Changes 2000/09/22 18:51:52 1.517
@@ -10,6 +10,8 @@
=item 1.24_01-dev
+plug leak in DIR_MERGE, thanks to Matt Sergeant for the spot
+
fixes to run and pass 'make test' on ActivePerl [Randy
Kobes, Gerald Richter]
Makefile.PL:post_initialize fix for win32, thanks to john
sterling for
1.103 +1 -1 modperl/src/modules/perl/mod_perl.h
Index: mod_perl.h
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.h,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -r1.102 -r1.103
--- mod_perl.h 2000/08/15 19:36:33 1.102
+++ mod_perl.h 2000/09/22 18:51:59 1.103
@@ -1132,7 +1132,7 @@
void perl_setup_env(request_rec *r);
SV *perl_bless_request_rec(request_rec *);
void perl_set_request_rec(request_rec *);
-void mod_perl_cleanup_av(void *data);
+void mod_perl_cleanup_sv(void *data);
void mod_perl_cleanup_handler(void *data);
void mod_perl_end_cleanup(void *data);
void mod_perl_register_cleanup(request_rec *r, SV *sv);
1.102 +18 -11modperl/src/modules/perl/perl_config.c
Index: perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- perl_config.c 2000/08/15 19:36:33 1.101
+++ perl_config.c 2000/09/22 18:52:00 1.102
@@ -436,7 +436,7 @@
sva = newSVpv(arg,0);
if(!*cmd) {
*cmd = newAV();
- register_cleanup(p, (void*)*cmd, mod_perl_cleanup_av,
mod_perl_noop);
+ register_cleanup(p, (void*)*cmd, mod_perl_cleanup_sv,
mod_perl_noop);
MP_TRACE_d(fprintf(stderr, "init `%s' stack\n", hook));
}
MP_TRACE_d(fprintf(stderr, "perl_cmd_push_handlers:
@%s, '%s'\n", hook, arg));
@@ -823,13 +823,13 @@
return NULL;
}
-void mod_perl_cleanup_av(void *data)
+void mod_perl_cleanup_sv(void *data)
{
-AV *av = (AV*)data;
-if(SvREFCNT((SV*)av)) {
- MP_TRACE_g(fprintf(stderr, "cleanup_av: SvREFCNT(0x%lx)==%d\n",
- (unsigned long)av, (int)SvREFCNT((SV*)av)));
- SvREFCNT_dec((SV*)av);
+SV *sv = (SV*)data;
+if (SvREFCNT(sv)) {
+MP_TRACE_g(fprintf(stderr, "cleanup_sv:
SvREFCNT(0x%lx)==%d\n",
+ (unsigned long)sv, (int)SvREFCNT(sv)));
+SvREFCNT_dec(sv);
}
}
@@ -929,7 +929,7 @@
*basevp = (mod_perl_perl_dir_config *)basev,
*addvp = (mod_perl_perl_dir_config *)addv;
-SV *sv,
+SV *sv=Nullsv,
*basesv = basevp ? basevp-obj : Nullsv,
*addsv = addvp ? addvp-obj : Nullsv;
@@ -958,16 +958,23 @@
if((perl_eval_ok(NULL) == OK) (count == 1)) {
sv = POPs;
++SvREFCNT(sv);
- mrg-obj = sv;
mrg-pclass = SvCLASS(sv);
}
PUTBACK;
FREETMPS;LEAVE;
}
else {
- mrg-obj = newSVsv(basesv);
- mrg-pclass = basevp-pclass;
+sv = newSVsv(basesv);
+mrg-pclass = basevp-pclass;
}
+
+if (sv) {
+mrg-obj = sv;
+register_cleanup(p, (void*)mrg,
+ perl_perl_cmd_cleanup, mod_perl_noop);
+
+}
+
return (void *)mrg;
}
RE: cvs commit: modperl/src/modules/perl mod_perl.c
the mod_perl.c update is causing conficts with the set_handlers patch...
the patch works, albit with lots of fuzz, but make yields:
mod_perl.c: In function `perl_run_stacked_handlers':
mod_perl.c:1342: parse error before `register'
make[3]: *** [mod_perl.o] Error 1
make[2]: *** [all] Error 1
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/apache_1.3.12/src'
make: *** [apache_httpd] Error 2
just in case you want to issue a new patch :)
--Geoff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 01, 2000 1:16 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: modperl/src/modules/perl mod_perl.c
dougm 00/08/31 22:15:42
Modified:.Changes
Leak Leak.xs
src/modules/perl mod_perl.c
Log:
fixes for ActivePerl
Revision ChangesPath
1.513 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.512
retrieving revision 1.513
diff -u -r1.512 -r1.513
--- Changes 2000/09/01 05:10:09 1.512
+++ Changes 2000/09/01 05:15:37 1.513
@@ -10,6 +10,8 @@
=item 1.24_01-dev
+fixes for ActivePerl [Gurusamy Sarathy [EMAIL PROTECTED]]
+
change apaci/Makefile.tmpl and src/modules/perl/Makefile so Perl's
include path comes before /usr/local/include, e.g. to make
sure Perl's
patchlevel.h is used, thanks to Ryan Morgan for the spot
1.4 +1 -1 modperl/Leak/Leak.xs
Index: Leak.xs
===
RCS file: /home/cvs/modperl/Leak/Leak.xs,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Leak.xs 1999/11/15 20:05:27 1.3
+++ Leak.xs 2000/09/01 05:15:40 1.4
@@ -121,7 +121,7 @@
{
char *state = lookup((struct hash_s **)p, sv, t_new);
if (state != t_old) {
- fprintf(stderr, "%s %p : ", state ? state : t_new, sv);
+ PerlIO_printf(PerlIO_stderr(), "%s %p : ", state ?
state : t_new, sv);
sv_dump(sv);
}
return hwm+1;
1.125 +21 -2 modperl/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.124
retrieving revision 1.125
diff -u -r1.124 -r1.125
--- mod_perl.c 2000/08/15 19:36:33 1.124
+++ mod_perl.c 2000/09/01 05:15:41 1.125
@@ -850,10 +850,21 @@
dPPDIR;
dPPREQ;
dTHR;
-GV *gv = gv_fetchpv("SIG", TRUE, SVt_PVHV);
+GV *gv;
+
+#ifdef USE_ITHREADS
+dTHX;
+
+if (!aTHX) {
+ PERL_SET_CONTEXT(perl);
+}
+#endif
(void)acquire_mutex(mod_perl_mutex);
-
+
+gv = gv_fetchpv("SIG", TRUE, SVt_PVHV);
+
+
#if 0
/* force 'PerlSendHeader On' for sub-requests
* e.g. Apache::Sandwich
@@ -1299,6 +1310,14 @@
I32 i, do_clear=FALSE;
SV *sub, **svp;
int hook_len = strlen(hook);
+
+#ifdef USE_ITHREADS
+dTHX;
+
+if (!aTHX) {
+ PERL_SET_CONTEXT(perl);
+}
+#endif
if(handlers == Nullav) {
if(hv_exists(stacked_handlers, hook, hook_len)) {
RE: anon CVS of modperl hangs?
doesn't work for me... cvsup seems to be up, though --Geoff -Original Message- From: Jens-Uwe Mager [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 23, 2000 2:54 PM To: [EMAIL PROTECTED] Subject: anon CVS of modperl hangs? I am trying to do an anon cvs update of modperl and it appears to hang without doing anything. I can cvs upd other projects. Could anyone try that and look if it works? -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone:+49 5131 709320 FAX: +49 5131 709325 Internet: [EMAIL PROTECTED]
