Re: cvs commit: modperl STATUS
[EMAIL PROTECTED] wrote:
> geoff 2002/08/07 12:39:00
>
> Modified:.STATUS
> Log:
> added bug report for print not looking at $\
the below patch seems to work, though I need to trace through the
rwrite_neg_trace() stuff to see what it actually does :) no
guarantees here, just some fiddling.
at any rate, if somebody who knows more about the perl API and XS
wants to use this as a starting point, feel free. I'm still unsure
about whether we want to implement this at all, but I had some free
time and...
--Geoff
Index: Apache.xs
===
RCS file: /home/cvspublic/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.125
diff -u -r1.125 Apache.xs
--- Apache.xs 6 Jul 2001 20:33:35 - 1.125
+++ Apache.xs 9 Aug 2002 17:44:00 -
@@ -1160,6 +1160,7 @@
PREINIT:
int i;
+int sent = 0;
char * buffer;
STRLEN len;
@@ -1170,7 +1171,6 @@
XSRETURN_IV(0);
for(i = 1; i <= items - 1; i++) {
- int sent = 0;
SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
(SV*)SvRV(ST(i)) : ST(i);
buffer = SvPV(sv, len);
@@ -1197,6 +1197,13 @@
RETVAL += sent;
#endif
}
+
+buffer = SvPV(GvSV(gv_fetchpv("\\", TRUE, SVt_PV)), len);
+
+if((sent = rwrite(buffer, len, r)) < 0) {
+rwrite_neg_trace(r);
+}
+RETVAL += sent;
OUTPUT:
RETVAL
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-2.0/Apache-Test/lib/Apache TestConfigPerl.pm
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 26, 2001 1:10 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: modperl-2.0/Apache-Test/lib/Apache
> TestConfigPerl.pm
>
>
> dougm 01/06/26 10:09:50
>
> Modified:Apache-Test/lib/Apache TestConfigPerl.pm
> Log:
> die in modperl_startup.pl if modperl_{inc,extra}.pl die
I'm playing around with Apache::Test again...
anyway, I thought modperl_extra.pl was supposed to be optional?
--Geoff
>
> Revision ChangesPath
> 1.13 +2 -1
> modperl-2.0/Apache-Test/lib/Apache/TestConfigPerl.pm
>
> Index: TestConfigPerl.pm
> ===
> RCS file:
> /home/cvs/modperl-2.0/Apache-Test/lib/Apache/TestConfigPerl.pm,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- TestConfigPerl.pm 2001/05/05 22:05:31 1.12
> +++ TestConfigPerl.pm 2001/06/26 17:09:46 1.13
> @@ -82,7 +82,8 @@
>BEGIN {
>use lib '$serverroot';
>for my \$file (qw(modperl_inc.pl modperl_extra.pl)) {
> -eval { require "conf/\$file" };
> +eval { require "conf/\$file" } or
> +die if \$@ !~ /^Can.t locate/;
>}
>}
>
>
>
>
>
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/Apache Apache.pm
a PerlSetVar foo following a PerlAddVar foo is supposed to reset the value
of foo, clearing the previous array (IIRC)
might be worth noting...
also, once you use the Apache::Table interface for either, you can call
set() in addition to add(). Doug thought that this might only set it for
the lifetime of the child, not permanently. I haven't verified this either
way (only that it works for my needs :)
--Geoff
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 25, 2000 10:39 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: modperl/Apache Apache.pm
>
>
> sbekman 00/11/25 07:39:25
>
> Modified:.Changes mod_perl.pod
>Apache Apache.pm
> Log:
> Documenting the new PerlAddVar httpd.conf directive. Please
> verify that I
> didn't do any mistakes since I've added this from my notes
> made about 6
> months ago. Thanks.
>
> Revision ChangesPath
> 1.549 +3 -0 modperl/Changes
>
> Index: Changes
> ===
> RCS file: /home/cvs/modperl/Changes,v
> retrieving revision 1.548
> retrieving revision 1.549
> diff -u -r1.548 -r1.549
> --- Changes 2000/11/07 23:09:19 1.548
> +++ Changes 2000/11/25 15:39:21 1.549
> @@ -10,6 +10,9 @@
>
>=item 1.24_02-dev
>
> +Documenting the new PerlAddVar httpd.conf directive
> +[Stas Bekman <[EMAIL PROTECTED]>]
> +
>new Apache::test::static_modules() method
>[Ken Williams <[EMAIL PROTECTED]>]
>
>
>
>
> 1.21 +28 -5 modperl/mod_perl.pod
>
> Index: mod_perl.pod
> ===
> RCS file: /home/cvs/modperl/mod_perl.pod,v
> retrieving revision 1.20
> retrieving revision 1.21
> diff -u -r1.20 -r1.21
> --- mod_perl.pod2000/03/05 23:46:30 1.20
> +++ mod_perl.pod2000/11/25 15:39:22 1.21
> @@ -167,15 +167,38 @@
>
>=item CONFIGURATION
>
> -The C directive provides a simple mechanism for passing
> -information from configuration files to Perl modules or
> Registry scripts:
> +The C and C directives provide a simple
> +mechanism for passing information from configuration files to Perl
> +modules or Registry scripts.
>
> +The C directive allows you to set a key/value pair.
> +
> PerlSetVar SomeKey SomeValue
>
>Perl modules or scripts retrieve configuration values using the
> -C<$r-Edir_config> method (see 'perldoc Apache').
> +C<$r-Edir_config> method.
> +
> + $SomeValue = $r->dir_config('SomeKey');
> +
> +The C directive allows you to emulate Perl arrays:
> +
> + PerlAddVar SomeKey FirstValue
> + PerlAddVar SomeKey SecondValue
> + ... ... ...
> + PerlAddVar SomeKey Nth-Value
> +
> +In the Perl modules the values are extracted using the
> +C<$r-Edir_config-Eget> method.
> +
> + @array = $r->dir_config->get('SomeKey');
> +
> +Alternatively in your code you can extend the setting with:
> +
> + $r->dir_config->add(SomeKey => 'Bar');
> +
> +C and C handle keys case-insensitively.
> +
>
> -C handles keys case-insensitively.
>
>=item GATEWAY_INTERFACE
>
> @@ -790,7 +813,7 @@
>
>=head1 REVISION
>
> -$Id: mod_perl.pod,v 1.20 2000/03/05 23:46:30 dougm Exp $
> +$Id: mod_perl.pod,v 1.21 2000/11/25 15:39:22 sbekman Exp $
>
>=head1 AUTHOR
>
>
>
>
> 1.59 +23 -0 modperl/Apache/Apache.pm
>
> Index: Apache.pm
> ===
> RCS file: /home/cvs/modperl/Apache/Apache.pm,v
> retrieving revision 1.58
> retrieving revision 1.59
> diff -u -r1.58 -r1.59
> --- Apache.pm 2000/11/07 23:09:25 1.58
> +++ Apache.pm 2000/11/25 15:39:24 1.59
> @@ -589,6 +589,29 @@
>I class when called in a scalar context with no
>"key" argument. See I.
>
> +
> +=item $r->dir_config->get( $key )
> +
> +Returns the value of a per-directory array variable
> specified by the
> +C directive.
> +
> + #
> + # PerlAddVar Key Value1
> + # PerlAddVar Key Value2
> + #
> +
> + my @val = $r->dir_config->get('Key');
> +
> +Alternatively in your code you can extend the setting with:
> +
> + $r->dir_config->add(Key => 'Value3');
> +
> +Keys are case-insensitive.
> +
> +Will return a I reference blessed into the
> +I class when called in a scalar context with no
> +"key" argument. See I.
> +
>=item $r->requires
>
>Returns an array reference of hash references, containing
> information
>
>
>
>
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] >
