Mod_Perl2 getting started

[joe]

Hi,
I’m finding the online documentation regarding mod_perl2 confusing
with regards to all the various modules dealing with request structures etc:
APR::Request, Apache2::Request, Apache2::RequestRec, Apache2::Upload,
etc.
Does anyone know of a tutorial or example code that sorts these out?
Ideally a simple one module working code response handler that illustrates 
access to the 
parsed request, handles args as querystrings and Post data, uploads a file or
two, and returns an html page to the requestor. Anyone have something like that?
Thanks very much in advance,
Joe N

Re: Mod_Perl2 getting started

[joe]

-Original Message- 
From: Fred Moyer

Try this link:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html
--
Yes, thanks - I've read that.



-Original Message- 
From: Fred Moyer

For handling POST data you will likely want to install libapreq2,
which is basically the equivalent of CGI:

http://search.cpan.org/dist/libapreq2/

use Apache2::Request;

   $req = Apache2::Request->new($r);
   @foo = $req->param("foo");
   $bar = $req->args("bar");
-

Thanks for the specifics- so something like this (below) should not
just die without an error message if I'm on track? (It just dies without
response
or error message - if I remove Apache2::Request->new($r) call it reponds
with the message to the browser..

So I 'm thinking libareq2 is not installed correctly yet?
My server provider is installing the apahce + perl etc. so
I'm partly at their mercy to get it correct. I just had no verified
test cases that I could say to them: This *should* work if the installation
is correct...

Thanks agains,
Joe N


##
package respHandler;
use strict;

use Apache2::Const qw(:common);
use Apache2::Request ();
1;

sub handler {
   my $r = shift;

   my $req = Apache2::Request->new($r);

   $r->content_type('text/plain');
   print "mod_perl 2.0 OK!\n";

   return OK;
}
#

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

The build system for the CMS is on GitHub here: 
https://github.com/SunStarSys/cms.  Full site builds clock in at around 500 
MB/s on modern hardware (NVMe + 8 cores).  But the real beauty is the 
Incremental Build Support in the product itself, so you only build what you 
changed.

 

From: Joe Schaefer  
Sent: Tuesday, August 16, 2022 12:08 AM
To: modperl@perl.apache.org
Subject: Experience running mod_perl2 with mpm_event on Solaris 11

 

You can read about it in the URL below, but I’ve had it running for over two 
years as the linchpin of a Perl-based CMS that The ASF used to use itself 
(under prefork). 

 

It screams under HTTP2.

 

See

   https://sunstarsys.com/CMS/

-- 

Joe Schaefer, Ph.D.

 
<https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA>
 

mailto:j...@sunstarsys.com> >

954.253.3732  

 

 


openpgp-digital-signature.asc
Description: PGP signature

:Sealed subs for typed lexicals

[joe]

Here’s some more fun I’ve been grinding out for the mod_perl community.  
Unfortunately I haven’t resolved all the issues with using this stuff in a 
mod_perl+ithread runtime, but if you figure out the right incantation please 
let me know:

 

https://sunstarsys.com/essays/perl7-sealed-lexicals


openpgp-digital-signature.asc
Description: PGP signature

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

To the best of my knowledge, the underlying problem with mod_perl+ithread is 
that it requires a reentrant malloc in libc.  I haven’t tested modern Perl 
releases against Linux/FreeBSD, but Solaris 11 is rock solid with ithreads and 
event_mpm.

 

From: Joe Schaefer  
Sent: Tuesday, August 16, 2022 12:08 AM
To: modperl@perl.apache.org
Subject: Experience running mod_perl2 with mpm_event on Solaris 11

 

You can read about it in the URL below, but I’ve had it running for over two 
years as the linchpin of a Perl-based CMS that The ASF used to use itself 
(under prefork). 

 

It screams under HTTP2.

 

See

   https://sunstarsys.com/CMS/

-- 

Joe Schaefer, Ph.D.

 
<https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA>
 

mailto:j...@sunstarsys.com> >

954.253.3732  

 

 


openpgp-digital-signature.asc
Description: PGP signature

RE: :Sealed subs for typed lexicals

[joe]

The build flags for Perl that I’m using on Solaris 11 are documented in the 
sealed.pm source code linked to from that webpage.

 

From: j...@sunstarsys.com  
Sent: Tuesday, August 16, 2022 11:13 AM
To: modperl@perl.apache.org
Subject: :Sealed subs for typed lexicals

 

Here’s some more fun I’ve been grinding out for the mod_perl community.  
Unfortunately I haven’t resolved all the issues with using this stuff in a 
mod_perl+ithread runtime, but if you figure out the right incantation please 
let me know:

 

https://sunstarsys.com/essays/perl7-sealed-lexicals


openpgp-digital-signature.asc
Description: PGP signature

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

Some HTTP/2 benchmarks from last year: 
https://www.youtube.com/watch?v=gf19vVF-G9E

 

From: j...@sunstarsys.com  
Sent: Tuesday, August 16, 2022 12:28 PM
To: modperl@perl.apache.org
Subject: RE: Experience running mod_perl2 with mpm_event on Solaris 11

 

To the best of my knowledge, the underlying problem with mod_perl+ithread is 
that it requires a reentrant malloc in libc.  I haven’t tested modern Perl 
releases against Linux/FreeBSD, but Solaris 11 is rock solid with ithreads and 
event_mpm.

 

From: Joe Schaefer mailto:j...@sunstarsys.com> > 
Sent: Tuesday, August 16, 2022 12:08 AM
To: modperl@perl.apache.org <mailto:modperl@perl.apache.org> 
Subject: Experience running mod_perl2 with mpm_event on Solaris 11

 

You can read about it in the URL below, but I’ve had it running for over two 
years as the linchpin of a Perl-based CMS that The ASF used to use itself 
(under prefork). 

 

It screams under HTTP2.

 

See

   https://sunstarsys.com/CMS/

-- 

Joe Schaefer, Ph.D.

 
<https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA>
 

mailto:j...@sunstarsys.com> >

954.253.3732  

 

 


openpgp-digital-signature.asc
Description: PGP signature

RE: :Sealed subs for typed lexicals

[joe]

Benchmarks from last year (based on openoffice.org):

https://www.youtube.com/watch?v=xr67QX6aMqU

 

From: j...@sunstarsys.com  
Sent: Tuesday, August 16, 2022 12:31 PM
To: modperl@perl.apache.org
Subject: RE: :Sealed subs for typed lexicals

 

The build flags for Perl that I’m using on Solaris 11 are documented in the 
sealed.pm source code linked to from that webpage.

 

From: j...@sunstarsys.com   mailto:j...@sunstarsys.com> > 
Sent: Tuesday, August 16, 2022 11:13 AM
To: modperl@perl.apache.org  
Subject: :Sealed subs for typed lexicals

 

Here’s some more fun I’ve been grinding out for the mod_perl community.  
Unfortunately I haven’t resolved all the issues with using this stuff in a 
mod_perl+ithread runtime, but if you figure out the right incantation please 
let me know:

 

https://sunstarsys.com/essays/perl7-sealed-lexicals


openpgp-digital-signature.asc
Description: PGP signature

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

We've been plagued by endless Segmentation Faults on non-Solaris systems, where 
the backtrace indicated the problem was in mod_perl -> Perl Code -> malloc (at 
the top of the frame).  For a while I thought p5p fixed this in 5.30+ releases, 
but since nobody confirmed that suspicion I think the problem is more on the 
OS/Platform level.

-Original Message-
From: Edward J. Sabol  
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list 
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, j...@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is 
> that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile 
Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed


openpgp-digital-signature.asc
Description: PGP signature

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

Whatever you do, do not use Perl's sbrk-based malloc implementation.  It's a 
disaster with ithreads.

-Original Message-
From: Edward J. Sabol  
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list 
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, j...@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is 
> that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile 
Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed


openpgp-digital-signature.asc
Description: PGP signature

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

I discuss different Dynamic Programming Language thread support at 
https://sunstarsys.com/CMS/technology.  The people in the Perl community at 
large who knock Perl5's ithreads support are doing nobody any favors.

-Original Message-
From: Edward J. Sabol  
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list 
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, j...@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is 
> that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile 
Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed


openpgp-digital-signature.asc
Description: PGP signature

RE: Experience running mod_perl2 with mpm_event on Solaris 11

[joe]

The problem is really confined to embedded uses of ithreads, because Perl 
itself will mutex-wrap the malloc calls.  In httpd, so do all apr_pool_t calls 
to malloc.  It's when the two memory management techniques are interacting that 
there is no application-level way to guard against thread contention in libc's 
malloc.

Mod_perl+ithreads are awesome, when used intelligently. You gain intelligence 
from experience trying to use it in a lot of ways that suck, until you hit one 
the path that yields success.

-Original Message-
From: Edward J. Sabol  
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list 
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, j...@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is 
> that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile 
Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed


openpgp-digital-signature.asc
Description: PGP signature

sealed.pm v4.0.0 is out

[joe]

See https://sunstarsys.com/essays/perl7-sealed-lexicals.  For the full effect, 
you will need to build B::Generate with this patched version instead: 
https://github.com/SunStarSys/cms/blob/master/Generate.xs

 

Sample mod_perl config + benchmarks:

 



StartServers 2

MinSpareThreads100

MaxSpareThreads500

ThreadLimit   1000

ThreadsPerChild100

MaxRequestWorkers  100

MaxConnectionsPerChild   0



 



  PerlSwitches -T -I/home/joesuf4/src/cms/lib

  PerlInterpStart 2

  PerlInterpMax 4

  PerlInterpMinSpare 1

  PerlInterpMaxSpare 4

  PerlInterpMaxRequests 100

  PerlOptions +GlobalRequest

 

  

Require all granted

AddHandler perl-script .pl

PerlResponseHandler ModPerl::Registry

Options +ExecCGI

  

 

  

Require all granted

  

 

  

ServerName localhost

DocumentRoot /home/joesuf4/src/trunk/content

Alias /perl-script /home/joesuf4/src/cms

  

 



 

 

ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl

This is ApacheBench, Version 2.3 <$Revision: 1879490 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

 

Benchmarking localhost (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

Completed 1 requests

Finished 1 requests

 

 

Server Software:Apache/2.4.52

Server Hostname:localhost

Server Port:80

 

Document Path:  /perl-script/enquiry.pl

Document Length:1329 bytes

 

Concurrency Level:  1000

Time taken for tests:   1.218 seconds

Complete requests:  1

Failed requests:0

Total transferred:  1501 bytes

HTML transferred:   1329 bytes

Requests per second:8207.94 [#/sec] (mean)

Time per request:   121.833 [ms] (mean)

Time per request:   0.122 [ms] (mean, across all concurrent requests)

Transfer rate:  12031.37 [Kbytes/sec] received

 

Connection Times (ms)

  min  mean[+/-sd] median   max

Connect:02   6.2  0  24

Processing: 4   93  49.6 82 458

Waiting:1   80  44.5 71 455

Total: 17   95  49.5 84 458

 

Percentage of the requests served within a certain time (ms)

  50% 84

  66%100

  75%112

  80%120

  90%147

  95%173

  98%233

  99%318

100%458 (longest request)

 

% pgrep -f apache2 | xargs -n1 ps -uwww

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

root  442827  0.0  0.1  18180 14244 ?Ss   11:27   0:00 
/usr/sbin/apache2 -k start

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

www-data  446387  1.7  1.5 7549352 129692 ?  Sl   11:28   0:12 
/usr/sbin/apache2 -k start

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

www-data  451006 15.2  1.5 7483708 128468 ?  Sl   11:39   0:10 
/usr/sbin/apache2 -k start

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

www-data  451317 11.7  1.4 7483772 119836 ?  Sl   11:39   0:07 
/usr/sbin/apache2 -k start

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

www-data  451629  6.4  1.3 7483804 113012 ?  Sl   11:39   0:03 
/usr/sbin/apache2 -k start

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND

www-data  451929  1.1  1.4 7483816 116668 ?  Sl   11:39   0:00 
/usr/sbin/apache2 -k start


openpgp-digital-signature.asc
Description: PGP signature

Moving away from pure application server tiers

[joe]

There is an emerging industry trend towards consolidation an integration of 
webstack technology, and mod_perl + mpm_event is well-positioned to eat 
everyone else’s lunch in this space.  The only real reason fastcgi-like 
frameworks won out over the past two decades is because threading was/is crap 
in Dynamic Programming Languages.  Nobody could successfully embed into a 
threaded webserver, so they went around celebrating multi-tiered architectures 
instead.

 

As the posted benchmark shows, you don’t need a massive investment in a cluster 
of horizontally scalable docker containers to service your dynamic content 
load.  Instead, you need to horizontally scale your modestly sized front-end 
apache servers running mpm_event+mod_perl with a Network (TCP-level) Load 
Balancer in the front.


openpgp-digital-signature.asc
Description: PGP signature

h2c benchmarks with same Ubuntu tune as before

[joe]

h2load -n 10 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl

starting benchmark...

spawning thread #0: 1000 total client(s). 10 total requests

Application protocol: h2c

progress: 10% done

progress: 20% done

progress: 30% done

progress: 40% done

progress: 50% done

progress: 60% done

progress: 70% done

progress: 80% done

progress: 90% done

progress: 100% done

 

finished in 11.60s, 8624.38 req/s, 11.13MB/s

requests: 10 total, 10 started, 10 done, 10 succeeded, 0 
failed, 0 errored, 0 timeout

status codes: 10 2xx, 0 3xx, 0 4xx, 0 5xx

traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space savings 
95.51%), 126.74MB (13290) data min max 
mean sd+/- sd

time for request:   225.73ms  11.31s   5.76s   3.09s58.62%

time for connect:15.40ms212.74ms 62.57ms 54.73ms87.50%

time to 1st byte:   261.01ms   9.04s   3.00s   2.01s68.00%

req/s   :   8.70   68.06   15.649.7385.70%

 

 


openpgp-digital-signature.asc
Description: PGP signature

sealed v4.1.1 released to CPAN

[joe]

New project home dedicated to sealed.pm maintenance is at 
https://github.com/SunStarSys/sealed

In the interest of saving more time and hassle, I put the best version I could 
come up with on CPAN, so you don’t need to clone the repository unless you want 
to benchmark the enquiry.pl ModPerl::Registry script.

 


openpgp-digital-signature.asc
Description: PGP signature

APR/Perl related security automation software released.

[joe]

Hot off the presses:

 

https://github.com/SunStarSys/orthrus/releases/tag/v1.0.0

 

 

https://github.com/SunStarSys/pty/releases/tag/v2.1.1

 

For hints on how to combine these products into your shell’s rc files, see

 

https://github.com/joesuf4/home/blob/wsl/.zshrc and 
https://github.com/joesuf4/home/blob/wsl/.zshenv

 

 

 

Joe Schaefer, Ph.D.

mailto:j...@sunstarsys.com> >

954.253.3732  

SunStar Systems CMS <https://sunstarsys.com/CMS/>  - The Original Markdown JAM 
Stack™

 


openpgp-digital-signature.asc
Description: PGP signature

sealed v4.1.8 deep recursion bugfix is on CPAN

[joe]

Be sure to pick up the latest CPAN release of sealed.pm if you want to be able 
to run this test script successfully:

 

https://github.com/SunStarSys/sealed/blob/master/test.sh

 

 

Joe Schaefer, Ph.D.

mailto:j...@sunstarsys.com> >

954.253.3732  

SunStar Systems CMS <https://sunstarsys.com/CMS/>  - The Original Markdown JAM 
Stack™

 


openpgp-digital-signature.asc
Description: PGP signature

sealed v4.1.9 on CPAN

[joe]

Includes ModPerl::RegistryCookerSealed which will monkey-patch your 
ModPerl::Registry runtime to use :Sealed handlers for your registry scripts.

 

Feedback/flames welcome.  Am I beating a dead horse with mod_perl + mpm_event 
in 2022?

 

Joe Schaefer, Ph.D.

mailto:j...@sunstarsys.com> >

954.253.3732  

SunStar Systems CMS <https://sunstarsys.com/CMS/>  - The Original Markdown JAM 
Stack™

 


openpgp-digital-signature.asc
Description: PGP signature

sealed.pm v4.3.1 is performing very well

[joe]

Hey guys,

 

I've been through January without a single core dump, running sealed.pm the
whole time with event mpm and mod_perl.

 

It's on CPAN without the mod_perl  dependency to ease adoption on a wider
scale.

 

Check it out, and see if it cores at all for you.  You might like the speed
bump on your core loops with OO-method calls in them.

 

 

 

Joe Schaefer, Ph.D.

< <mailto:j...@sunstarsys.com> j...@sunstarsys.com>

  954.253.3732



 <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack
WikiT

 

 

Re: Apache::Request->instance(undef)

[Joe Schaefer]

Dave Rolsky <[EMAIL PROTECTED]> writes:

> If you call Apache::Request->instance with an undefined value, it dies
> when it tries to call pnotes() on that argument.
> 
> It seems to me that it should simply return a false value if given
> undef. This can happen if you have a piece of code like this:
> 
>  my $r = Apache::Request->instance(Apache->request);
> 
> which may be called during server startup or during a request.

Would something like this be ok?

  sub instance {
my ($class, $r) = @_;
return undef unless defined $r;
if (my $apreq = $r->pnotes('apreq')) {
return $apreq;
}
my $new_req = $class->new($r, @_);
$r->pnotes('apreq', $new_req);
return $new_req;
  }

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [mp2] Apache::Cookie

[Joe Schaefer]

"Swen Schillig" <[EMAIL PROTECTED]> writes:

> Hi *
> 
> I have a problem with Apache::Cookie setting the
> expiration value correctly.
> Meaning whatever I specify, the default value is used instead ( which
> is now or -1) !

[...]

> Am I doing something wrong or is this a known bug ??

Bug, previously unknown.

> Any help ?

It looks to me like there may be a problem in apreq_cookie.c
(it may not be computing the "expires" date correctly for Netscape 
cookies).  Which version of libapr are you using?

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [mp2] Apache::Cookie

[Joe Schaefer]

Joe Schaefer <[EMAIL PROTECTED]> writes:

> It looks to me like there may be a problem in apreq_cookie.c
> (it may not be computing the "expires" date correctly for Netscape 
> cookies).  Which version of libapr are you using?

If you're using the latest libapr, this patch to libapreq2
should fix the problem.

Index: src/apreq_cookie.c
===
RCS file: /home/cvs/httpd-apreq-2/src/apreq_cookie.c,v
retrieving revision 1.20
diff -u -r1.20 apreq_cookie.c
--- src/apreq_cookie.c  26 Sep 2003 13:58:33 -  1.20
+++ src/apreq_cookie.c  18 Dec 2003 04:57:37 -
@@ -89,7 +89,7 @@
 if (!strcasecmp(time_str, "now"))
 c->max_age = 0;
 else
-c->max_age = apreq_atoi64t(time_str);
+c->max_age = apr_time_from_sec(apreq_atoi64t(time_str));
 }
 
 static int has_rfc_cookie(void *ctx, const char *key, const char *val)
@@ -478,7 +478,7 @@
 return apr_snprintf(buf, len, format, c->v.name, c->v.data, c->version,
 NULL2EMPTY(c->path), NULL2EMPTY(c->domain), 
 NULL2EMPTY(c->port), NULL2EMPTY(c->comment), 
-NULL2EMPTY(c->commentURL), c->max_age);
+        NULL2EMPTY(c->commentURL), apr_time_sec(c->max_age));
 }


-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [mp2] Apache::Cookie

[Joe Schaefer]

"Swen Schillig" <[EMAIL PROTECTED]> writes:

> Joe
> 
> Thanks for the patch the expiration is working fine now
> even though the test fails :-)
> 
> 
> t/testall -v
> All APREQ Tests:
> Cookie:   ..F.
> Param:...
> Parsers:  ..
> 
> 9 tests run:  8 passed, 1 failed, 0 not implemented.
> 
> Failed tests in Cookie:
> 1) netscape_cookie: expected
> >
> foo=bar; path=/quux; domain=example.com; expires=Thu, 18-Dec-2003 11:51:26
> GMT
> <
> but saw
> >
> foo=bar; path=/quux; domain=example.com; expires=Fri, 17-Dec-2004 11:50:55
> GMT
> <

The failure shows that apreq_expires is broken also.
The fix is identical - wrap apr_time_from_sec around
the result of apreq_atoi64t.

> While testing this I figured another problem, the secure flag
> is not working either !

Oops!

> But the path and the domain attributes are !
> So maybe you'll find some time to fix this as well :-)
> 
> Anyway, thanks for your help and the solution.
> 
> BTW, when will the fix be part of the cvs ?

The fixes are ready; what's missing are the corresponding
tests to ensure the bugs don't reappear.

nb- folks can always add more tests to demonstrate
bugs without necessarily having a corresponding fix.
A patch to the test suite which demonstrates a bug
is absolutely the best kind of bug report.

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Mod Perl + Apache Error logs, extend DBILogger

[Joe Schaefer]

<[EMAIL PROTECTED]> writes:

> This information is most helpful in understanding what is going on.
> That would be the logical thing to think that the during the perlhandler
> phase the content() gets sucked up and isn't available for 

[...]

> This is what I have below, the problem I'm trying to solve is getting
> the params (text field etc.) that were passed to a cgi script.  This
> Apache module is being called in my httpd.conf by "PerlLogHandler
> Apache::ErrorLogger".  

Unfortunately there's no good solution for your problem in mp1-land,
because the POST data winds up wherever the content handler (or some
earlier handler) puts it.  Unless that's using Apache::Request as 
well, I'm afraid there's no way to get at the POST data with libapreq.

However, because of the input filtering design built into apache2,
you _can_ do what you want with mp2/apreq2, no matter what the content
handler is (it doesn't even need to be perl-related).  All you'd need 
to do is make sure mod_apreq's filter gets inserted before the 
content-handler takes over, and then Apache::Request will provide full 
access to the parsed POST data.

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

[JOB] mod_perl Portal Installation/Customization

[Joe Breeden]

Title: [JOB] mod_perl Portal Installation/Customization






I am looking for someone to recommend, install, and modify a mod_perl based web portal that can integrate with a PostgreSQL database we already have that authenticates jabber clients. This is a telecommute job. 


I realize this is not a lot of information, but it is a pretty straightforward thing. Experience with Jabber (http://www.jabber.org) is a plus. If you are interested, reply off-list and I will send you a basic requirements document that describes what we are looking for and the environment the servers are in. 

Thanks,




--Joe Breeden

--

Fake Shemp

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

"Pete Smith" <[EMAIL PROTECTED]> writes:

[...]

> my $image_upload = $r->upload('image');
> my $file_handle = $image_upload->fh();
> 
> read ($file_handle, my $full_image_data, (stat($file_handle))[7]);
> 
> my $imager = Imager->new();
> 
> $imager->open(data => $full_image_data, type => 'jpeg');
> my ($width) = imgsize(\$full_image_data);
> 
> 
> I now know that I could pass the file handle to Imager and Image::Size
> instead of turning into a scalar stream, but that isn't the problem.
> 
> I have discovered that Apache::Request for mod_perl2 has changed the
> fh method to bb, which apparently returns an APR::Brigade (object I
> presume) instead of a file handle. 
> 
> I have looked for documentation for APR::Brigade, but can find none. I
> have no idea what it is!

APR::Brigade is, well, the perl glue for libaprutil's apr_brigade_t C struct.  
Along with buckets, they are used throughout the filter api, both in
apache2 and mp2 (collectively referred to as "bucket brigades").

> Could somebody please point me in the right direction as to how I can
> achieve the above in mod_perl2?

In your mp1 code, you are simply slurping the upload into
$full_image_data; with apreq2 you can do that with a bucket 
brigade via

  my $bb = $req->upload('image')->bb;
  my $full_image_data = "";

  while (my $b = $bb->first) {
 $b->read(my $buffer);
 $full_image_data .= $buffer;
 $b->remove;
  }

I'm sure there are better ways to use the brigade API
though.  The C API for brigades has a "flatten" function- 
does anyone know if mp2 has glue for that yet?

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: libapreq2 and FreeBSD

[Joe Schaefer]

Martin Nilsson <[EMAIL PROTECTED]> writes:

> I'm trying to install libapreq2-2.02-dev on FreeBSD 4.9 with Perl
> 5.6.1 and Apache 2.048 mod_perl2-1.99r12 all installed from ports.

Wonderful!  Thanks alot!

[...]

> Files:
> ///usr/local/lib/perl5/5.6.1/man/man3/Apache::Cookie.3
> ///usr/local/lib/perl5/5.6.1/man/man3/Apache::Request.3

[...]

> ///usr/local/lib/perl5/site_perl/5.6.1/mach/auto/libapreq2/.packlist
> 
> Thanks for any help making this work!

The perl glue looks ok to me.  Where did mod_apreq.so 
and libapreq2.so wind up going? mod_apreq should be in
apache2's module directory, and libapreq2 should be
alongside libaprutil.

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Geoffrey Young <[EMAIL PROTECTED]> writes:

[...]

> I'm not as familiar with brigades as I should be, but does
> it save you the iteration process or is it just a substitute for
> reading to a buffer? 

It'd save you the iteration process (it's an APR::Brigade method,
not APR::Bucket), but would not destroy the buckets within the 
brigade (hmm, does APR::Brigade have a DESTROY method?).  

The advantage here is you'd be able to accomplish this
in one or two lines of perl, ie.

  my $upload_data = $req->upload('file')->bb->flatten;


-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Geoffrey Young <[EMAIL PROTECTED]> writes:

> Joe Schaefer wrote:
> >   my $upload_data = $req->upload('file')->bb->flatten;
> 
> oooh, nice.  I can definitely see that being a useful idiom.

Not sure if it'd be better for flatten to take $upload_data as 
an argument and return a status code instead, but I'll happily
leave that decision for the implementer :-).

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:


[...]

> It doesn't sound like a good idea. Users ain't need to mess with
> bucket brigades, unless they really want to. If the upload is always
> going through the temp file, why making things complex for the users?

Exactly because it is NOT always going through a temp file.  
Just look further upthread- this particular user doesn't
even *want* a temp file, just the data.  Why should he need
to make all those "open/read/write/close file" system calls 
if he doesn't need them?

> In any case it's the best to hide the internals behind an API,
> so you can do:  
>
> my $upload_data = $req->upload('file')->slurp;
> 
> and inside slurp you have the C API to do anything you need. How
> does that sound? 

That's a possibility, but I fail to see its advantage over
APR::Brigade exposing flatten().  It is part of the C API
after all, eh?  Why shouldn't perl programmers have access
to it?

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> You need the filehandle only if you use the temp file. In which case
> bbs are irrelevant. If you use slurp then there is are no
> filehandles. I think these are orthogonal.

Agreed- my earlier +1 was for both adding a slurp() method and 
marking the output as tainted.

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [mp2] Apache Request and libapreq2 Cookie woes

[Joe Schaefer]

"Beau E. Cox" <[EMAIL PROTECTED]> writes:

[...]

>   ($self->{cookie_class} is 'Apache::Cookie')
>   my $cookie =
>  $self->{cookie_class}->new( Apache->request, ... );
>   -- OK

This is correct usage, because Apache->request is an 
Apache::RequestRec object in mp2.

> 
>   my $cookie =
>  $self->{cookie_class}->new( $self->apache_req, ... );
>   -- Segmentation fault (11)
> 
>   my $apr = Apache::Request->new( $self->apache_req );
>   -- Segmentation fault (11)

These are (currently) incorrect calls, because the argument 
to new() MUST be an Apache::RequestRec object, not an
Apache::Request object.  The segfault is of course a bug
in Apache::Request, but in the meantime you can avoid it by 
using env() to pull the base Apache::RequestRec object out of 
your Apache::Request object:

  my $cookie = $self->{cookie_class}->new($self->apache_req->env,...);
  my $apr = $self->apache_req; # (no need to call new() here)

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->status does not accept a valid parameter

[Joe Schaefer]

<[EMAIL PROTECTED]> writes:

[...]

> $r->status(Apache::HTTP_MULTI_STATUS);
> or
> $r->status(207);
> 
> always results in the following
> 
> Usage: Apache::Request::status(sv) at API/Modes.pm
> line 235.

$r->status is read-only for Apache::Request objects;
you either want

  $r->env->status(207); # env() yields Apache::RequestRec obj

or

  $r->SUPER::status(207); # Apache::RequestRec is the base
  # class for Apache::Request (in mp2)


Not sure if this solves your overall problem,
but it should resolve this part of it.

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] Am I leaking memory?

[Joe Schaefer]

"Beau E. Cox" <[EMAIL PROTECTED]> writes:

[...]

> The only place in my Mason changes I can see anything funny is:
> 
> # This gets the proper request object all in one fell swoop.  We
> # don't want to copy it because if we do something like assign an
> # Apache::Request object to a variable currently containing a
> # plain Apache object, we leak memory.  This means we'd have to
> # use multiple variables to avoid this, which is annoying.
> my $r =
> $r_sub->( $self->args_method eq 'mod_perl' ?
>   Apache::Request->new( $_[0] ) :
>   $_[0]
> );
> 
> I changed:
>   Apache::Request->instance( $_[0] ) :
> to:
>   Apache::Request->new( $_[0] ) :
> 
> Is that causing trouble? 

No, your change is fine.  AFAICT that comment pertains to an esoteric 
problem with object cleanup in libapreq/mp1, but the bug doesn't 
seem to be carried over into mp2/apreq2 (the apreq2 test suite has 
a test for it).

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Kevin Bosak <[EMAIL PROTECTED]> writes:

> I too am having issues with file uploads using mod_perl2.  I've gotten
> the beta of Apache::Request but it looks like from this thread that
> there's not yet a way to retrieve the uploaded file.  Is this true?

No, it's not true at all.  If you don't need to read the contents of the
upload, but just need to store it in a file somewhere, use 
$upload->link("/path/to/local/file"). If you do need to read the 
contents, use the APR::Brigade API on $upload->bb. A future version 
of Apache::Request may have include convenience methods (like slurp(), 
etc.), but you can certainly get at the uploaded file using the current 
version.

The brigade API is a big performance-win for libapreq2, since it allows 
us to use a zero-copy design on file uploads until the file gets too 
big to store in memory.  The size limit is currently 256K, but the size
will be configurable in future versions.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Kevin Bosak <[EMAIL PROTECTED]> writes:

> I can get the file's name but the upload
> is simply not getting linked/saved.  I'm sure it's probably something
> I'm doing wrong, but I don't know what.  Here's the relevant lines
> from my code: 
> 
>my $upload = $r->upload('file');
>my $filename = $upload->filename;
>$upload->link("/path/to/local/$filename");
> 
> Is there something I can do to troubleshoot this?

Three things to check:

  1) be sure $filename is valid (it really should be marked as tainted),
  2) be sure "/path/to/local/$filename" is on the same device
  (filesystem) as your temporary directory (see the docs for 
  Apache::Request::new regarding TEMP_DIR).
  3) check the return value of $upload->link, if it's false (undef) then
 there was a problem- usually the trouble is caused by one of the above.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Kevin Bosak <[EMAIL PROTECTED]> writes:

> Thanks for the advice.
> I checked and $upload->link does indeed return false.  I'm guessing
> it's because of something with TEMP_DIR you said, but my lack of
> knowledge is keeping me from getting this resolved.  How do I
> determine what TEMP_DIR has been set to?  

At the moment, grepping Mason's source files for TEMP_DIR or TMPDIR is
probably the only solution.  I don't think the current Apache::Request 
for mp2 exposes enough of the C API to be of any help to you.

> I'm using Mason with ApacheHandler2 that I believe sets up the
> Apache::Request object but I'm still a little unclear on how
> everything fits together.  I could definitely use another "nudge" in
> the right direction.

If you're using glibc, the sledgehammer approach is to have the 
sysadmin set/export the TMPDIR environment variable prior to server 
startup, ie.

  % TMPDIR=/path/to/my/tmpdir apachectl restart

This will override any TEMP_DIR settings coming from calls to
Apache::Request::new().

btw- I'm planning to $upload->link so that it will handle the
cross-device situation more gracefully (by making a full copy 
of the tempfile should the internal PerlLIO_link fail).

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: File uploads using Apache:;request in mod_perl2

[Joe Schaefer]

Kevin Bosak <[EMAIL PROTECTED]> writes:

> Thanks again for the help but still no luck.
> I set the TMPDIR environment variable manually and restarted apache
> but still can't get the upload file in my script and nothing's being
> written to the tmpdir.  If there's anything else I can try please let
> me know but I may just end up having to use CGI.pm for uploads.

Try replacing the apreq_xs_upload_link() function in 

  glue/perl/xsbuilder/Apache/Request/Apache__Request.h

with the following one; rebuild and install it.  If this 
doesn't solve your problem, the next release should include more
helpful diagnostics, but until then CGI.pm is always available.


APR_INLINE
static XS(apreq_xs_upload_link)
{
dXSARGS;
MAGIC *mg;
void *env;
const char *name, *fname;
apr_bucket_brigade *bb;
apr_file_t *f;

if (items != 2 || !SvROK(ST(0)))
Perl_croak(aTHX_ "Usage: $upload->link($name)");

if (!(mg = mg_find(SvRV(ST(0)), PERL_MAGIC_ext)))
Perl_croak(aTHX_ "$upload->link($name): can't find env");

env = mg->mg_ptr;
bb = apreq_xs_rv2param(ST(0))->bb;
name = SvPV_nolen(ST(1));

f = apreq_brigade_spoolfile(bb);
if (f == NULL) {
apr_off_t len;
apr_status_t s;
const apr_int32_t flags = APR_CREATE | APR_EXCL | APR_WRITE |
APR_READ | APR_BINARY | APR_BUFFERED;

s = apr_file_open(&f, name, flags,
  APR_OS_DEFAULT,
  apreq_env_pool(env));
if (s != APR_SUCCESS || 
apreq_brigade_fwrite(f, &len, bb) != APR_SUCCESS)
XSRETURN_UNDEF;

XSRETURN_YES;
}
if (apr_file_name_get(&fname, f) != APR_SUCCESS)
XSRETURN_UNDEF;

if (PerlLIO_link(fname, name) >= 0)
XSRETURN_YES;
else {
apr_status_t s = apr_file_copy(fname, name,
   APR_OS_DEFAULT, 
   apreq_env_pool(env));
if (s == APR_SUCCESS)
XSRETURN_YES;
}

XSRETURN_UNDEF;
}

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Cookie and CGI::Cookie Interoperability

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

> James Taylor wrote:
> > I'm having difficulty getting my mod_perl scripts and then my
> > non-mod_perl scripts reading cookies between each other.  I have a
> > mod_perl TransHandler that sets a cookie via Apache::Cookie, and
> > then I have some scripts in my /cgi-bin that try and read the cookie
> > using basic CGI::Cookie.  It doesn't appear to be working
> > whatsoever, as the Apache::Cookie script can't read any of the
> > cookies set by CGI::Cookie and vice-versa.   I tried ditching
> > Apache::Cookie in the transhandler and using CGI::Cookie as well,
> > but still the two can't see each other.
> > Any ideas what would cause something like this?
>
> 
> You can't do it this way. Since when you try to retrieve the cookie
> from your cgi, it reads the cookies from $ENV{HTTP_COOKIE} ||
> $ENV{COOKIE}, whereas your TransHandler doesn't set those env-vars
> (one of the two), and that's what it should do. Moreover, most likely
> it should use $r->subprocess_env to do that, and not setting %ENV.

Amplififying on Stas's reply, there's a big difference between incoming 
(request) cookies and outgoing (response) cookies.  When you set 
(or bake) a cookie, it's _outgoing_, so you're ultimately creating 
something that will only appear in the *response* headers.  On the 
other hand, when these modules parse cookies, they're only looking 
at the *request* headers, since that's where the *incoming* cookies 
appear.

IOW, you shouldn't try to set/bake cookies as a means of passing
data from one handler to another one *inside the same request*.  
Cookies are a means of passing data between two different requests, 
and the module APIs reflect that.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] Using MP2 to rewrite URLs based on POST Body data

[Joe Schaefer]

"Greg Balmer" <[EMAIL PROTECTED]> writes:

[...]

> Basically our service has a single access point
> http://ourhost.com/Service and I want to be able to examine the POSTed
> (XML) content of requests for keywords in the body and rewrite the
> incomming url as follows - 
> 
> Request BODY :  "..keyword1.." then rewrite the URL
> to  http://ourhost.com/Service-method1
> Request BODY :  "..keyword2.." then rewrite the URL
> to  http://ourhost.com/Service-method2
> ...

If there was an xml parser available for libapreq2, you could use
Apache::Request to do this without any worries.

[...]

> I'm a bit of a newbie to this stuff, but I think this may be
> achievable with InputFilters, so I was really looking for any pointers
> that anyone could give.

It is, but you need to be very careful about spooling the post data for
the redirected url.  This is basically what mod_apreq.c does in 
libapreq2, but it's pretty tricky.  Perhaps convincing apreq-dev@ 
to support xml would be your best bet.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Problem with modperl2/apache2/apreq2 upload

[Joe Schaefer]

"Ken Burcham" <[EMAIL PROTECTED]> writes:

>   I've been reading and trying things all day to no avail which 
> usually means I'm doing something stupid.  I have a perl apache 
> module running under Apache 2.0.48/Mod_perl 
> 1.99_13/libapreq2.02_02 and I'm trying to take a file upload.  
> 
>   I'm getting a segfault whenever I call $req->upload with a 
> parameter:
> 
> my $upload = $req->upload('somefilename');

That's certainly supposed to work, assuming 'somefilename' is
the name of the upload widget in your HTML form. Can you post 
a backtrace for the segfault?

> I can, however, call: my @uploads = $req->upload; and it returns 
> to me an array of parm names.  In apache1, a call to ->upload 
> would return to me just upload objects whereas in apache2 it is 
> apparently returning every param name on the form.  Is that 
> right?

That is correct.  In apache1 the uploads formed a linked list
internally, but that's no longer true in apreq2. In apreq2 
$req->upload follows the same interface pattern as $req->param.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Problem with modperl2/apache2/apreq2 upload

[Joe Schaefer]

"Ken Burcham" <[EMAIL PROTECTED]> writes:

> > That's certainly supposed to work, assuming 'somefilename' is
> > the name of the upload widget in your HTML form. Can you post 
> > a backtrace for the segfault?
> 
> Sure... umm... how do I do that?  :)
> 
> I'm still pretty new to perl.  

Segfaults arise from buggy C code. For instructions on generating
a backtrace, read

  http://perl.apache.org/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults

> > 
> > That is correct.  In apache1 the uploads formed a linked list
> > internally, but that's no longer true in apreq2. In apreq2 
> > $req->upload follows the same interface pattern as $req->param.
> 
> How do I get to just the upload items?  Or do I test via $upload-
> >info/type?


  No need to test anything: $req->upload() works just like 
$req->param(), but it is restricted to uploads only.  For example

  my $upload_table_ref = $req->upload; # APR::Table ref of uploads

  foreach my $name (keys %$upload_table_ref) {
 my @uploads = $req->upload($name); # Array of Apache::Upload
# objects having name = $name
 # do something with @uploads
  }

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Problem with modperl2/apache2/apreq2 upload

[Joe Schaefer]

"Ken Burcham" <[EMAIL PROTECTED]> writes:

> Ok, I might be on to something...
> 
> I think the segfault is coming when I call 'upload' with a non-
> upload field...  But since calling 'upload' without a name 
> returns to me a list of variable names that include non-upload 
> fields, iterating through guarantees me to segfault:
> 
> (NOTE: resourceurl is the only 'file' field on my form with 23 
> other 'text' fields)
> 
> my $q = Apache::Request->new($r);
> 
> my @uploads = $q->upload;

OK, I see the problem now.  In list context $q->upload()
is failing to filter out the non-upload keys.  It should 
get fixed in the next release, but in the meantime try 
using $q->upload() in scalar context. That will give you 
an Apache::Upload::Table (@ISA=APR::Table) to work with.
The table will only contain uploads, and since it's a 
tied hash, you can iterate over it using keys() or each().

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Problem with modperl2/apache2/apreq2 upload

[Joe Schaefer]

"Ken Burcham" <[EMAIL PROTECTED]> writes:

[...]

> foreach my $key (keys %{$uploads})
> {
>warn "Uploader found $key";
> 
>my $upload = $uploads->{$key};
> 
>warn "Found $upload->filename";
> 
> }

[...]

> But nothing else as if my foreach finds nothing...  What am I 
> missing?  :) 

No clue at the moment-  foreach(keys %$uploads) should loop once
for the upload file.  I'll look into that problem also.

[...]

> warn "There was a problem uploading: $uploadfile" unless $upload-
> >link($uploadfile);
> 
> Am I on the right track with this?  It fails...  In another 
> thread (http://www.gossamer-
> threads.com/archive/mod_perl_C1/modperl_F7/File_uploads_using_Apa
> che:%3Brequest_in_mod_perl2_P101676), you mention 3 possibilities 
> as to why it could fail and it implicates a temp directory...  

Yes, your problem with link() is likely the temp dir location.
That problem is resolved in current cvs, and with the patch I 
posted on that thread.

> 
> I'm expecting it to write to that file.  The $upload_dir exists, 
> but the file obviously doesn't because I'm trying to upload it...  
> 
> Do I need to ->bb and then write it?  

No, link() will do it for you; use current cvs or apply the patch.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Missing submit button if after a file field

[Joe Schaefer]

"Rob Mueller" <[EMAIL PROTECTED]> writes:

> I submitted this to the lib-apreq mailing list ([EMAIL PROTECTED])
> but didn't hear anything back, so I thought I'd try here...

Odd that you say there was no answer, when the ensuing apreq-dev@
discussion  (http://marc.theaimsgroup.com/?t=10814601034&r=1&w=2)

  1) researched the issue and determined the cause, tracing it back to a 
 similar report on February 6, 2002 (from you!) regarding Mozilla 0.97:

http://marc.theaimsgroup.com/?l=apache-modperl&m=101295988431701&q=raw

  2) determined that the missing CRLF from Konqueror is still
 RFC-compliant:

http://marc.theaimsgroup.com/?l=apreq-dev&m=108184431529065&w=2

  3) resulted in a patch to httpd-apreq-2 cvs over the weekend:

http://marc.theaimsgroup.com/?l=apreq-cvs&m=108225244312182&w=2

There is no patch available for httpd-apreq (libapreq-1), because
nobody (myself included) has volunteered one yet.  It may wind up 
simply being documented as a bug if nobody fixes it before the
next release of httpd-apreq.

I'll answer your email directly below, in the hopes of clearing this
up for you so some motivated person might patch httpd-apreq.

[...excellent bug report elided...]

> To be honest, I haven't dug through the spec to see if buttons are supposed
> to come before other fields, but as far as I can tell, this problem only
> happens if the button field is submitted by the browser immediately after a
> file field, 

The empty file field coming from Konqueror is missing a CRLF.  That
does not violate RFC 2046, however it breaks httpd-apreq's mfd parser
(probably CGI.pm's also) because the parser assumes that CRLF will be
there.

This is the reason why the subsequent "Submit" button is missing from the 
params: the parser interpreted its block as being the upload file's contents.
The missing CRLF causes the parser to skip over the boundary string
separating the (empty) file block from the "Submit" button's block.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: building 64-bit

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> It should be possible to automate this search by getting cvs version bumped up
> incrementally and grepping for that split line, untill the change is
> found. It'd be a nice addition to our toolset. 

What's wrong with cvs annotate here?

gemini:~/src/apache/modperl$ cvs annotate Makefile.PL | grep PERL_EXTRA_CFLAGS

Annotations for Makefile.PL
***
1.174(dougm23-Dec-00): $PERL_EXTRA_CFLAGS = "";
1.4  (hartill  10-Feb-98):  $PERL_EXTRA_CFLAGS .= " -D${k}=1";
1.86 (dougm28-Aug-98):  $PERL_EXTRA_CFLAGS .= " -D$_=1";
1.81 (dougm30-Jul-98): $PERL_EXTRA_CFLAGS .= " -DPERL_SAFE_STARTUP=1";
1.201(dougm23-May-02): $PERL_EXTRA_CFLAGS .= " $Config{ccflags}";
1.201(dougm23-May-02): $PERL_EXTRA_CFLAGS =~ s/-D_GNU_SOURCE//;
1.144(dougm07-Mar-00):  if($PERL_EXTRA_CFLAGS) {
1.144(dougm07-Mar-00):  $PERL_EXTRA_CFLAGS = join(" ", split(",",  
$PERL_EXTRA_CFLAGS));
1.144(dougm07-Mar-00):  $PERL_EXTRA_CFLAGS =~ s/\s+/ /g;
1.144(dougm07-Mar-00):  $PERL_EXTRA_CFLAGS .= " -g";
1.144(dougm07-Mar-00):  $PERL_EXTRA_CFLAGS .= " 
-DPERL_DESTRUCT_LEVEL=$PERL_DESTRUCT_LEVEL"
1.55 (dougm25-Jun-98):  if($PERL_EXTRA_CFLAGS) {
1.55 (dougm25-Jun-98):  $cmd .= qq(CFLAGS="$PERL_EXTRA_CFLAGS" );
1.4  (hartill  10-Feb-98): $inc .= " $PERL_EXTRA_CFLAGS" if 
$PERL_EXTRA_CFLAGS;
gemini:~/src/apache/modperl$ cvs log -r1.144  Makefile.PL

RCS file: /home/cvspublic/modperl/Makefile.PL,v
Working file: Makefile.PL
head: 1.219
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 219;   selected revisions: 1
description:

revision 1.144
date: 2000/03/07 03:12:36;  author: dougm;  state: Exp;  lines: +26 -25
fix Makefile.PL if $USE_APXS && $PERL_DEBUG
=

Doesn't look like the cvs log is going to be of much help;
perhaps checking the list archives in Feb/March 2000 will
turn up something useful.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

mp2 : Win32::GetShortPathName usage

[Random Joe]

Greetings,

I am trying to build mod_perl 1.99_13 on Win 2000 (VC
6.0).

In mod_perl-1.99_13\lib\ModPerl\BuildOptions.pm around
lines 110 - 111

if (Apache::Build::WIN32()) {
# MP_AP_PREFIX may not contain spaces
require Win32;
$val = Win32::GetShortPathName($val);
}

Why do we need to require Win32.pm ?
Win32::GetShortPathName is in Perl Core. 

I also have another doubt. 

I want to avoid using Win32.pm. I have built perl
5.8.3 native on win32. I notice that mod_perl uses
Win32::Process in
Apache-Test\lib\Apache\TestServer.pm. If I ignore this
usage or workaround it - can I safetly avoid using
Win32::* (libwin32) w.r.t to mod_perl ?

regards
srp




__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mp2 : Win32::GetShortPathName usage

[Random Joe]

--- Randy Kobes <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jun 2004, Random Joe wrote:
> 
> > Greetings,
> >
> > I am trying to build mod_perl 1.99_13 on Win 2000
> (VC
> > 6.0).
> >
> > In mod_perl-1.99_13\lib\ModPerl\BuildOptions.pm
> around
> > lines 110 - 111
> >
> > if (Apache::Build::WIN32()) {
> > # MP_AP_PREFIX may not contain spaces
> > require Win32;
> > $val = Win32::GetShortPathName($val);
> > }
> >
> > Why do we need to require Win32.pm ?
> > Win32::GetShortPathName is in Perl Core.
> 
> You're right - that require of Win32 could be
> removed.
> 
> > I also have another doubt.
> >
> > I want to avoid using Win32.pm. I have built perl
> > 5.8.3 native on win32. I notice that mod_perl uses
> > Win32::Process in
> > Apache-Test\lib\Apache\TestServer.pm. If I ignore
> this
> > usage or workaround it - can I safetly avoid using
> > Win32::* (libwin32) w.r.t to mod_perl ?
> 
> Win32::Process is used to run the tests, which is
> probably
> a good idea ... Was there a problem installing
> libwin32?
> Or some other reason you want to avoid it?

Non technical reason :-) Becomes another thing I have
to document, maintain etc

regards
srp

> 
> -- 
> best regards,
> randy kobes
> 
> -- 
> Report problems: http://perl.apache.org/bugs/
> Mail list info:
> http://perl.apache.org/maillist/modperl.html
> List etiquette:
> http://perl.apache.org/maillist/email-etiquette.html
> 





__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: mp2 : Win32::GetShortPathName usage

[Random Joe]

--- Randy Kobes <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jun 2004, Random Joe wrote:
> 
> > --- Randy Kobes <[EMAIL PROTECTED]>
> wrote:
> > > On Wed, 2 Jun 2004, Random Joe wrote:
> > >
> > > > Greetings,
> > > >
> > > > I am trying to build mod_perl 1.99_13 on Win
> 2000
> > > (VC 6.0).
> > > >
> > > > In
> mod_perl-1.99_13\lib\ModPerl\BuildOptions.pm
> > > > around lines 110 - 111
> > > >
> > > > if (Apache::Build::WIN32()) {
> > > > # MP_AP_PREFIX may not contain spaces
> > > > require Win32;
> > > > $val = Win32::GetShortPathName($val);
> > > > }
> > > >
> > > > Why do we need to require Win32.pm ?
> > > > Win32::GetShortPathName is in Perl Core.
> > >
> > > You're right - that require of Win32 could be
> > > removed.
> > >
> > > > I also have another doubt.
> > > >
> > > > I want to avoid using Win32.pm. I have built
> perl
> > > > 5.8.3 native on win32. I notice that mod_perl
> uses
> > > > Win32::Process in
> > > > Apache-Test\lib\Apache\TestServer.pm. If I
> ignore
> > > > this usage or workaround it - can I safetly
> avoid
> > > > using Win32::* (libwin32) w.r.t to mod_perl ?
> > >
> > > Win32::Process is used to run the tests, which
> is
> > > probably
> > > a good idea ... Was there a problem installing
> > > libwin32?
> > > Or some other reason you want to avoid it?
> >
> > Non technical reason :-) Becomes another thing I
> have
> > to document, maintain etc
> 
> Fair enough :) If you don't want to run the tests,
> you could
> get away without Win32::Process, but
> Win32::GetShortPathName
> is still required to build it. So you'd either have
> to
> install libwin32 anyway to build it, or comment out
> the
> relevant Win32::* calls.

oops, i got confused. If Win32::GetShortPathName and
brothers are in Perl Core why should I need to install
libwin32 ?

perl-src/win32/win32.c defines GetShortPathName -
which seems to be calling the system's
GetShortPathName() directly.


> 
> However, it's *really* recommended to run the test
> suite,
> which is pretty extensive; if you run into problems
> using

Yes, I do plan to use the test suite "as part of
nightly test runs". My question was more about whether
mod_perl required any Win32::* stuff during normal
operations. Apparently it does not.

regards
srp


> mod_perl, and ask here about it, one of the first
> questions
> asked is how well the tests fared.
> 
> -- 
> best regards,
> randy
> 
> -- 
> Report problems: http://perl.apache.org/bugs/
> Mail list info:
> http://perl.apache.org/maillist/modperl.html
> List etiquette:
> http://perl.apache.org/maillist/email-etiquette.html
> 





__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

libapreq2-2.03-dev-rc3 available for testing

[Joe Schaefer]

Folks,

Please take this release candidate out for a test drive

  http://cvs.apache.org/~joes/libapreq2-2.03-dev-rc3.tar.gz  

and report back your success/failure.  I'd like to get 
this new developer release of libapreq2 on CPAN this weekend,
but I need a few volunteers to test it and report back
on their experience (please include platform and version
numbers for perl, mp2, and apache2 in your response).

== Changes with libapreq2-2.03-dev ==

- C API [joes]
  "Objectify" cookie/jar API: s/apreq_(make|serialize)_cookie/apreq_cookie_$1/
  and reordering args so the cookie/jar object is always the first argument.
  Macros added to provide source-compatibility with the old names.

- Perl API [joes]
  Added $upload->slurp($data), which reads the contents of the file
  upload "$upload" into the scalar "$data".

- C API [joes, randyk]
  apreq_run_(hook|parser) are macros, so they are capitalized now.
  Fixed apreq_params_as_string() and added apreq_params_as_array().
  Reworked definitions of APREQ_DECLARE_HOOK, APREQ_DECLARE_PARSER 
  and apreq_(parser|hook)_t, hopefully to be more Win32 friendly.
  Also updated the documentation.

- C API [joes]
  Compensate for a missing CRLF in empty file upload block, which 
  actually complies with RFC 2046 Section 5.1.1.  Konqueror (version unknown)
  and Mozilla 0.9.7 are known to emit such blocks.

- Perl API [joes]
  $req->upload() in list context failed to filter out non-uploads.
  Also $req->upload("nonexistent-key-name") segfaults.

- Perl test suite
  t/TEST.PL must run parent class' pre_configure to get the
  configuration right

- C API [joes]
  apreq_brigade_concat() wasn't supplying the final EOS bucket
  to large brigades (>256K), which somtimes caused the prefetch 
  loop in mod_apreq.c's apreq_filter() to hang.

- Documentation [joes]
  CHANGES file reformatted, removing dates & other clutter 
  as Stas suggests.

- C API [joes]
  Rewrote cgi_read() in apreq_env.c and reworked mod_apreq.c 
  to enforce apreq_env_max_body() settings.

- C API [joes]
  Fixed bug in url_parser code- missing context brigade was
  needed to track key-value pairs which span multiple buckets.

- C API [joes]
  API modifications: removed struct apreq_cfg_t, adding
  new apreq_env hooks max_body, max_brigade_len, and temp_dir.
  Folded apreq_parsers.h into apreq_params.h and modified the arguments 
  to apreq_run_parser() and apreq_run_hook(). Renamed 
  apreq_parser_t's content_type as enctype and apreq_copy_brigade()
  as apreq_brigade_copy().
  These changes make libapreq2.so.2.0.5 incompatible with earlier 
  versions.

- Perl API [stas]
  Include ppport.h from blead-perl to support older perls.
  Add a proper support for ithreads.

- C API [Swen Schillig, joes]
  Fixed bug in calculation of Netscape cookie expiration dates.
  apr_time_t is measured in microseconds, not seconds, which
  threw off the arithmetic; apr_time_from_sec was needed for
  the conversion.

- C API [Max Kellermann]
  Fix segfault caused by invalid %-escape sequence in query string.
==


Thanks!

-- 
Joe Schaefer



-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[ANNOUNCE] libapreq2-2.03-dev released

[Joe Schaefer]

The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 2.03 developer release of libapreq2. 

The libapreq2-2.03_04-dev.tar.gz package has been released under 
the new Apache License version 2.0.  The package is now available 
through the ASF mirrors

  http://www.apache.org/dyn/closer.cgi/httpd/libapreq2-2.03_04-dev.tar.gz
  http://www.apache.org/dyn/closer.cgi/httpd/libapreq2-2.03_04-dev.tar.gz.asc

and has entered CPAN as

  file: $CPAN/authors/id/J/JO/JOESUF/libapreq2-2.03_04-dev.tar.gz
  size: 447648 bytes
   md5: 18cefa860f15812ed35c5e1eb52f9a0a


==
Changes with libapreq2-2.03-dev

- C API [joes]
  "Objectify" cookie/jar API: s/apreq_(make|serialize)_cookie/apreq_cookie_$1/
  and reordering args so the cookie/jar object is always the first argument.
  Macros added to provide source-compatibility with the old names.

- Perl API [joes]
  Added $upload->slurp($data), which reads the contents of the file
  upload "$upload" into the scalar "$data".

- C API [joes, randyk]
  apreq_run_(hook|parser) are macros, so they are capitalized now.
  Fixed apreq_params_as_string() and added apreq_params_as_array().
  Reworked definitions of APREQ_DECLARE_HOOK, APREQ_DECLARE_PARSER 
  and apreq_(parser|hook)_t, hopefully to be more Win32 friendly.
  Also updated the documentation.

- C API [joes]
  Compensate for a missing CRLF in empty file upload block, which 
  actually complies with RFC 2046 Section 5.1.1.  Konqueror (version unknown)
  and Mozilla 0.9.7 are known to emit such blocks.

- Perl API [joes]
  $req->upload() in list context failed to filter out non-uploads.
  Also $req->upload("nonexistent-key-name") segfaults.

- Perl test suite
  t/TEST.PL must run parent class' pre_configure to get the
  configuration right

- C API [joes]
  apreq_brigade_concat() wasn't supplying the final EOS bucket
  to large brigades (>256K), which somtimes caused the prefetch 
  loop in mod_apreq.c's apreq_filter() to hang.

- Documentation [joes]
  CHANGES file reformatted, removing dates & other clutter 
  as Stas suggests.

- C API [joes]
  Rewrote cgi_read() in apreq_env.c and reworked mod_apreq.c 
  to enforce apreq_env_max_body() settings.

- C API [joes]
  Fixed bug in url_parser code- missing context brigade was
  needed to track key-value pairs which span multiple buckets.

- C API [joes]
  API modifications: removed struct apreq_cfg_t, adding
  new apreq_env hooks max_body, max_brigade_len, and temp_dir.
  Folded apreq_parsers.h into apreq_params.h and modified the arguments 
  to apreq_run_parser() and apreq_run_hook(). Renamed 
  apreq_parser_t's content_type as enctype and apreq_copy_brigade()
  as apreq_brigade_copy().
  These changes make libapreq2.so.2.0.5 incompatible with earlier 
  versions.

- Perl API [stas]
  Include ppport.h from blead-perl to support older perls.
  Add a proper support for ithreads.

- C API [Swen Schillig, joes]
  Fixed bug in calculation of Netscape cookie expiration dates.
  apr_time_t is measured in microseconds, not seconds, which
  threw off the arithmetic; apr_time_from_sec was needed for
  the conversion.

- C API [Max Kellermann]
  Fix segfault caused by invalid %-escape sequence in query string.
==

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request

[Joe Schaefer]

"David Hofmann" <[EMAIL PROTECTED]> writes:

> I see that there a development version. Is there a stable version that
> works for Mod Perl 2.0 or something the can be easily put in it's place?

No, there isn't.  My guess is that there will only be one more
developer release in a few months, which will include the recent
SSL bugfixes and full support for Apache::Request in CGI mode
(libapreq2 already works with CGI; mp2 is being reshuffled a bit
to allow Apache::Request to work there as well).

I'd really like to see a stable release happen before November's
Apachecon, and I don't expect Apache::Request to change much between 
now and then. 

Even so, now is a very good time to try it out, because you actually
may want some things changed before we "stabilize" it :-).  There
are plenty of open issues in the httpd-apreq-2 STATUS file that would
benefit from user-feedback.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Kreimendahl, Chad J wrote:
> > http://httpd.apache.org/apreq/
> > Install using one of the following methods:
> > (easiest way)
> > perl Makefile.PL --with-apache2-apxs=/path/to/apache2/bin/apxs
> > (or, same thing, different method)
> > ./configure --with-apache2-apxs=/path/to/apache2/bin/apxs
> > --enable-perl-glue --with-perl=/path/to/perl/binary
> > (then, the standard)
> > make
> > make test
> > make install
> > This appears to install over top of the existing module, unlike
> > installing in an Apache2 directory (like those of us who had mp1 and mp2
> > running).  So there may be problems in mp1 once this is done... I'd test
> > it, but my mp1 is long gone.
> 
> That's strange. I get it installed under Apache2/ subdir (assuming
> that you had mp2 installed into Apache2/ subdir). You may want to
> report all the details to the apreq-dev mailing list.

+1.  The 1.X and 2.X versions of Apache::Request should happily coexist
if mp2 was configured with MP_INST_APACHE2=1.  Only the installed Unix 
manpages will overlap; anything else is a bug and should be reported to 
[EMAIL PROTECTED]

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] losing POST vars with PerlOutputFilterHandler+mod_proxy

[Joe Schaefer]

"Eric J. Hansen" <[EMAIL PROTECTED]> writes:

> I'm having a problem whereby I can't access POST CGI variables when using
> an output filter (PerlOutputFilterHandler) alongside mod_proxy.
> Parameters on the URL (GET) work just fine, its just the POST variables
> that are missing.
> 
> My setup is that I'm using a mod_proxy reverse proxy to fetch some remote
> content, then doing some analysis on the content using an output filter.

The problem is likely that the apreq filter has not been added to 
the input filter chain in time to read the POST data.

There are two solutions to this problem:

  1) Write a filter init handler for you filter that instantiates an
 Apache::Request object.  See

http://perl.apache.org/docs/2.0/api/Apache/Filter.html#C_FilterInitHandler_

  2) Use .htaccess or your server config to ensure the apreq input filter
 is active for this request with "AddInputFilter APREQ" or somesuch.

I recommend using (1), and falling back to (2) until you get (1) working.

> I suspect this has something to do with mod_proxy consuming the
> request data - i.e., once the data of the HTTP request is read, its gone 

Correct.

[...]

> sub handler   {   # (filter)
>   my $f = shift;
>   my $r = $f->r;
> 
>   if ( ! $r->notes('not_first_bucket') ) {
>   $r->notes->set('not_first_bucket' => 1);
> 
>   my $ApReq = Apache::Request->new($r);
>   my $CgiArgsRef = $ApReq->param;
> 
>   # log CGI variables for debug...
>   $CgiArgsRef->do( sub {
>   $r->log_error("CGI parameter: '" . $_[0] . 
>"' = '" . $_[1] . "'"); 
>   return 1;
>   });
>   )
> 
>   return Apache::DECLINED;
> }
> 
> And if I install this as an INPUT filter, 
  ^

Danger, Will Robinson!  Generally speaking, you should *not* use 
Apache::Request::param inside an input filter.  Otherwise you run 
the very real risk of an infinite recursion error.  The apreq 
filter will always insert itself as the very *last* input filter in 
the chain, which means it'll call *your* input filter in order to 
get at the requested POST data.  It looks like you managed to carefully
avoid the infinite recursion in your example, but I'm not sure the 
underlying Apache::DECLINED perl magic is smart enough to handle the 
reentry-  thus the 502.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] losing POST vars with PerlOutputFilterHandler+mod_proxy

[Joe Schaefer]

Geoffrey Young <[EMAIL PROTECTED]> writes:

> Eric J. Hansen wrote:
> > Thanks, Joe!  I implemented your suggestion (1), and the following
> > works nicely... (added to my request filter)
> > 
> > sub init : FilterInitHandler {
> > my $f = shift;
> > my $r = $f->r;
> 
> wow, a FilterInitHandler in the wild.  guess it was a good idea to
> support that after all ;)

IIRC apreq-as-filter was part of the motivation for httpd to even
implement the filter init hook, so yeah, that *was* a good idea :-).

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> Temporarily we could link to cvs.apache.org, e.g.:
> http://cvs.apache.org/viewcvs.cgi/*checkout*/httpd-apreq-2/glue/perl/xsbuilder/Apache/Cookie/Cookie_pod

Probably you want the html version, in which case it's best to just link

  http://cvs.apache.org/~joes/libapreq2-2.04-dev/docs/html/modules.html

A more permanent link on the apreq website will be available before the 
next release.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request

[Joe Schaefer]

Kemin Zhou <[EMAIL PROTECTED]> writes:

[...]

> perl ../../build/xsbuilder.pl run
> 
> This told me to install another package

What was the name of the package?  ExtUtils::XSBuilder?

> Install the required package then run this again.  It will generate
> the needed file.
> 
> running perl Makefile.PL will not detect this dependency.

It's supposed to, so let's try to fix that.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> There is little value and a huge overhead in building the table files
> by each user (not talking about extra dependencies). 

I know our build/xsbuilder.pl has Win32-specific code in it, so
I'm somewhat reluctant to simply generate and bundle the pre-built
tables.

> It might be a good idea for apreq2 to store the output of recdescent
> under cvs and hand it ready to the users. That's similar to what mp2
> does (though it uses C::Scan to do the C parsing).

Not opposed in principle, I just don't want to be personally 
involved in maintaining those tables.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] APR::Table / Apache::Request usage question

[Joe Schaefer]

Nicholas Studt <[EMAIL PROTECTED]> writes:

[...]

> When I read this value from a POST or a GET everything works happily.
> When I try to add something to the table the add happens without
> event, but I can not read the set value back.

Actually a segfault is likely here, because Apache::Request::Table
does not provide a (safe) overload for APR::Table::add().  You cannot
currently assign params to any of the APR::Table-derived objects in
apreq2, but this isue should be addressed before the next release.

> Am I missing something in how APR::Table works or is there a better
> construct I should be using?

I haven't tested this, but it should be safe to forcibly re-bless
Cparam> into an APR::Table object and do what you want
(without breaking anything).  Do not try this with $req->args or
$req->body though.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Uploading files

[Joe Schaefer]

Kemin Zhou <[EMAIL PROTECTED]> writes:

> To the Developers,
> 
> I saw this in the documentation for Apache::Request
> 
> for file upload
> 
>tempname [XXX- Does this mesh with brigade API?]
>
>  Provides the name of the spool file. This method is reserved for
>  debugging purposes, and is possibly subject to change in a future
>  version of Apache::Request.
> 
> From a user's point view, this methods has to be available to the
> users and not removed in the future.

[...]

Despite my past grumblings to the contrary, I've added support for tempname
to httpd-apreq-2's current-cvs.  I don't know what sort of security
implications you are concerned about, but perhaps the best thing to do
is simply not use tempname, instead using link() - and then delete the 
linked file yourself once the external app is done with it.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Uploading files

[Joe Schaefer]

Kemin Zhou <[EMAIL PROTECTED]> writes:

> Joe Schaefer wrote:

[...]

> >Despite my past grumblings to the contrary, I've added support for
> >tempname to httpd-apreq-2's current-cvs.

[...]

> Thanks for the help.  The tempname is not available in mp2.  

You misunderstood me.  When I read your article, I thought you
gave sufficient reasons as to why apreq2 should support tempname,
so I wrote an implementation and committed it *right then* to cvs.
Prior to your article tempname() was unimplemented in apreq2 (in fact 
it was *removed* from the documentation not more than a day or two 
prior to your post).

[...]

> I don't know how this is implemented.  I used to write my own file
> upload method.  Some of my web applications still use these methods.  
> It is very simple.  

That's all fine and dandy, but apreq2 is operating under more stringent
requirements.  There is a coercive effect when you implement your own
data parser: unless everyone else adopts your implementation, somebody
inevitably gets left out of the loop.

apreq2 imposes no adoption requirements on other modules. For instance
you can implement an auth handler with apreq2 that parses the post
data, which then decides to accept the request and hand it off to 
a cgi script.  The cgi script will still have the full POST data 
available for it to use/parse.

Or you can write a content handler that uses apreq2 which parses the
post data and then does an internal redirect to the proxy handler.  The
proxied server will still see the original POST data, without any extra
code by the content-handler author.

[...]

> Put more thoughts into uploads could benefit the future.

Thanks, we'll try.  In the meantime I've rolled another snapshot
of current-cvs that you're very welcome to try

  http://cvs.apache.org/~joes/libapreq2-2.04-dev.tar.gz

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [MP2 Bug] test case t/apr-ext/uuid.t failuer

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> That's your problem, it fails to find those libs. Please show us the
> output of: 
> 
> apr-config --link-ld --libs
> apu-config --link-ld --libs

Stas, mp2 may need

  apr-config --link-ld --ldflags --libs

on some platforms.  I've seen this on FreeBSD, for
example.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: missing param from post using apache::request

[Joe Schaefer]

"Ken Burcham" <[EMAIL PROTECTED]> writes:

> Hey guys,
> 
>   I submitted a bug report to [EMAIL PROTECTED] and it got returned
> without comment...  (maybe it was the wrong place?)  so I guess i'll
> post it here since I know Joe Schaefer monitors this list :).

Yup, I'm here.  Problems with param parsing aren't mp2 bugs, they're
apreq bugs.  Reporting them on [EMAIL PROTECTED] is probably best, but
discussing this here on [EMAIL PROTECTED] should be fine.

> Any ideas what's going on here?  Thanks!

Not at the moment, but I don't understand this "add the character and post" 
business.  Could you please be more specific about that, and please also
remove the GCX modules from the handler you'd like me to test (unless
the bug disappears without them).

Thanks!

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: missing param from post using apache::request

[Joe Schaefer]

"Ken Burcham" <[EMAIL PROTECTED]> writes:

> Actually, one weird thing is that if I use CGI.pm instead of 
> Apache::Request the parm is there just fine...  Maybe it handles 
> it differently or something...  

Sorry, I haven't been able to reproduce the bug (using 
Mozilla to submit the form) yet.  Changing the enctype
just changes the parser. Since the mfd parser seems ok 
with your form-data, the problem likely lies in the urlencoded 
parser in libapreq2/src/apreq_parsers.c.

Still digging though... any chance you could test this
against current-cvs for apreq and mp2?

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: missing param from post using apache::request

[Joe Schaefer]

Joe Schaefer <[EMAIL PROTECTED]> writes:

[...]

> Still digging though... 

Bug found in src/apreq_parsers.c:split_urlword.
The problem is that apreq_decode can fail if
a bucket ends in the middle of an escape sequence,
which causes the parser to abort.

This will be fixed before 2.04-dev is released
(probably sometime over the weekend if you're
tracking curent cvs).

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: CGI's Generate Pages With Numbers

[Joe Schaefer]

"Kent, Mr. John \(Contractor\)" <[EMAIL PROTECTED]> writes:

> Any idea what would cause a call to a cgi script to return a
> non-displayable page with numbers (below)? 

[...]

> Transfer-Encoding: chunked

That would, assuming you're viewing the page with a 
user-agent which doesn't understand it.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 upload gotcha

[Joe Schaefer]

John Williams <[EMAIL PROTECTED]> writes:

[...]

> Request for libapreq2 developers: Could you please either remove or
> document this gotcha?

The gotcha here is really a generic issue (ie working with
bucket brigades through the APR:: modules) so maybe it is
(or needs to be) addressed in the mp2 docs.  However I wonder
why you want to remove the buckets at all?  With $upload->bb
you probably shouldn't do that, because you're throwing
data away that later modules/filters may yet want to use. 

Btw this is something that changed from 2.02 to 2.03 (we used
to give you a copy of the brigade, so you *had* to remove
the buckets yourself).  There's also a new io() method
coming in the coming 3.04-dev release that gives you a
brigade copy like $upload->bb used to do, but it has a
TIEHANDLE api superimposed.  That way you can use perl's 
read() or <> operator to consume the buckets in $upload->io().


-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 upload gotcha

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:


[...]

> Interesting. What's the type of the bucket? Is that a file bucket?

I believe so.  File buckets morph into two buckets
when you read from them.  The current bucket transforms
into a heap bucket, and a new file bucket is inserted behind 
*it*.

However, if you remove the file bucket from the brigade
*before* you read from it, the morphed file bucket created
during the read winds up in limbo, not in the original brigade.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 upload gotcha

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> Moving $b->remove to the end makes the code horribly kludgy. It's
> better to change the idiom to step through the buckets instead of
> removing them. Adjusting John's sample code:
> 
>  my $bb = $r->upload('file')->bb();
>  open(OUT,">/tmp/test_file");
>  for (my $b = $bb->first; $b; $b = $bb->next($b)) {
>  $b->read(my $data);
>  print OUT $data;
>  }
>  close OUT;
> 
> Joe, does this idiom work fine with file buckets? 

In principle this is fine, but there is a practical issue
to consider: this idiom has the effect of reading the file
bucket back into memory until there are no more file buckets
left in the brigade.  If the upload was large enough to
warrant a spool file to begin with, slurping it all back into
memory as chunks is not a good idea.

What I'm going to recommend in the Apache::Upload docs is ask 
people to use the TIEHANDLE api for io() instead:

  my $io = $req->upload("foo")->io;
  print while read $io, $_, 8000; # read() will manage the buckets for you


> We need to write a test for this case, but at the moment we have no
> API to create file buckets. I guess we could test that in an output
> filter and have a response handler call sendfile, which should create
> a bucket of file type.
> 
> BTW, John you could also do:
> 
>my $bb = $r->upload('file')->bb();
>my $len = $bb->flatten(my $data);
>print OUT $data;
> 
> though it's probably less memory-usage effective.

Hah, aren't *you* the guy that asked for $upload->slurp(my $data)?
Now you're recommending $upload->bb->flatten, which does exactly
the same thing (deja vu?).  

So, can we go back and get rid of slurp() now? :-)

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 upload gotcha

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> > [...]
> >
> >>Moving $b->remove to the end makes the code horribly kludgy. It's
> >>better to change the idiom to step through the buckets instead of
> >>removing them. Adjusting John's sample code:
> >>
> >> my $bb = $r->upload('file')->bb();
> >> open(OUT,">/tmp/test_file");
> >> for (my $b = $bb->first; $b; $b = $bb->next($b)) {
> >> $b->read(my $data);
> >> print OUT $data;
> >> }
> >> close OUT;
> >>

[...]

> > What I'm going to recommend in the Apache::Upload docs is ask people
> > to use the TIEHANDLE api for io() instead:
> >   my $io = $req->upload("foo")->io;
> >   print while read $io, $_, 8000; # read() will manage the buckets for you
> 
> Do you mean the difference is in being able to request chunks of
> limited size (8k?). Otherwise the two are equivalent.

No, they are not at all equivalent, because io *deletes* the buckets
as it reads them, which puts them right back into the bucket allocator 
for immediate reuse.  Witness:

  % CONTENT_TYPE="multipart/form-data; boundary=AaB03x"
  % PERL5OPT="-Mblib -MApache2 -MApache::Upload -MAPR::Bucket -MAPR::Pool"
  % export CONTENT_TYPE PERL5OPT
  % ls -sh ~/tmp/mfd_post_data
  5.0M /home/joe/tmp/mfd_post_data

  % perl -wle '$r = Apache::Request->new(APR::Pool->new); \
$bb = $r->upload("pics")->bb; \
for ($b = $bb->first; $b; $b= $bb->next($b)) {$b->read($_)}   \
system "ps u $$" ' < ~/tmp/mfd_post_data
  USER   PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
  joe  32201  0.0  0.4 38424 9952 ?S+   05:34   0:00 perl -wle $r = Ap

  % perl -wle '$r = Apache::Request->new(APR::Pool->new); 
my $io = $r->upload("pics")->io; 
1 while $io->read($_); 
system "ps u $$" ' < ~/tmp/mfd_post_data
  USER   PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
  joe  32203  0.0  0.2 33408 4908 ?S+   05:36   0:00 perl -wle $r = Ap

That's a difference of 5MB, or exactly one full copy of the upload
file into RAM.  This is because the for(...) loop transforms the
sole file bucket into a string of heap buckets that aren't cleaned
up until the pool goes away.

[...]

> In any case, I think $r->upload->slurp(my $data) is a goodness as it doesn't
> require the user to even be aware of the internal representation.

I was just teasing :-).  Anyway's we can at least rip out the
XS duplication in Apache::Upload and just write slurp in 2 lines
of perl via bb->flatten.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 upload gotcha

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> Looks exactly the same internally as the perl for loop. The only
> difference is that it calls apr_bucket_delete when it's done with
> it. Which you can do with the for() loop just the same.

But you didn't *write* that, so we must be talking past each other.  
I thought the problem this thread was really about was 

  If I'm trying to read all the data in a bucket brigade,
  *when* is it ok to remove or delete a bucket from the brigade?

The straightforward answer is that you should wait
until after you've called $b->read(), because read() 
has all kinds of side effects.  The rest of this dialog 
seems to have taken us nowhere, so I'll just stop here.


-- 
Joe Schaefer

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Accessing form mutiples

[Joe Schaefer]

"Dermot Paikkos" <[EMAIL PROTECTED]> writes:


[...]

>   foreach my $param ($r->param) {
> print STDERR "\$r->$param = ".scalar($r->param($param))."\n";
> #   $hash_ref->{$r->param($param)} = 0;

Have you tried using a slice there?

 @{$hash_ref}{$r->param($param)} = (); # values are now undef, not 0

You need the slice syntax to put $r->param($param) in list context.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Raw header and body of HTTP request

[Joe Schaefer]

Honza Pazdziora <[EMAIL PROTECTED]> writes:

> I'm using Apache2, mod_perl2. I use Apache::Request, so that I can get
> to ->args and ->body data easily.
> 
> At the same time, I would sometimes need to get the raw body data.

If the body data is getting lost when you use Apache::Request
in mp2, that's a bug in Apache::Request.

[...]

> Is there any way to retrieve the raw content (and headers)

You could write a input filter that goes in front of HTTP_IN
(protocol or connection type), which would see the byte stream 
in raw form (headers unparsed, data unchunked).


-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Raw header and body of HTTP request

[Joe Schaefer]

Honza Pazdziora <[EMAIL PROTECTED]> writes:

[...]

> and it works great. However, I'm probably missing something but how
> do you do equivalent of $r->read($buffer, 64_000) multiple times? 

Be sure you've got

  use Apache::RequestRecIO;

somewhere, and everything should work just fine.  If not,
please file a bug report.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Raw header and body of HTTP request

[Joe Schaefer]

Joe Schaefer <[EMAIL PROTECTED]> writes:

> Be sure you've got
> 
>   use Apache::RequestRecIO;
   ^^^

Sorry, typo- should be Apache::RequestIO.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request multivalued parameters

[Joe Schaefer]

"David Hofmann" <[EMAIL PROTECTED]> writes:

> I have a form where several of the in hidden fields are named the same thing
> with diffrent values.
> 
> With CGI.pm the I can use %in = $readquery->Vars; to put everything in a
> hash. Then I break the values base on \0.
> 
> What the best way to do this with Apache::Request, and how does it handle
> multivalued parameters ?

You have quite a few options here:

  1) Work with the Apache::Request::Table

$t = $req->param;

 and use each(%$t), keys(%$t) and values(%$t) to iterate over the params
 in document order (query_string args come first, then the POST
 data in the order it was received).  To get all entries for a 
 given parameter, you can use 
  
@foo_vals = $t->get("foo");

 You can also use $t->do(...) to iterate over the table entries with
 a callback sub.

  2) Think of the $req->param method as a "smart-hash", and use it in
 the same way you'd use CGI::param (since that's the method 
 it is patterened after).

  3) Try to stop using the $readquery->Vars API, since $req->param is 
 able to decode binary data with embedded '\0' values in them.
 If you can't bring yourself to that, just write your own converter:

sub Vars {
my $req = shift;
map { $_ => join "\0", $req->param($_) } $req->param;
}


I hope this helps.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::Request multivalued parameters

[Joe Schaefer]

"David Hofmann" <[EMAIL PROTECTED]> writes:

> I was using this system and exporting the results to %in so that I
> could use $in{VAR} in my program.
> 
> Which allows me to do
> 
> $temp= "BOB";
> print "$temp = $in{$temp}\n";
> 
> To my knowledge, which may be lacking considering I just recently
> started playing with refrences, if I use option 1 or 2 I would have to:
> 
> $temp= "BOB";
> $bob = $t->get($temp);
> print "$temp = $bob\n";
> 
> Is there where way to put the $t->get inside of a "s?

Use $t as a hash-ref:

  print "$temp = $t->{$temp}\n";

That only prints the first $temp param (unless your iterating
over the table with each(), which magically pulls the current
$temp param).  But you probably don't want $temp multivalued 
here unless you don't mind having

  print "$temp = $in{$temp}\n";

embed those \0's in your HTML.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 versus everything else

[Joe Schaefer]

Ken Burcham <[EMAIL PROTECTED]> writes:

> I heartily agree... it would have saved me a lot of time coming into
> mod_perl2  land...

The reason it isn't in mp2 is IMO largely a matter of timing (and a bit of
politics).  apreq-dev wanted to get the C stuff included in httpd's
distro, that way mp2 could provide the wrappers for it.  However apreq2
was just getting started when httpd-2.0 was declared stable, so
the earliest inclusion point apreq-dev could hope for was the 2.2 line.
We're stable enough now to be considering 2.04-dev as the final
developer's release (more on that soon), so it's really up to the 
httpd community to determine whether or not httpd-2.2 users will 
benefit from it.


-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Missing POST data

[Joe Schaefer]

David Graves <[EMAIL PROTECTED]> writes:

[...]

> If I stop using all mod-perl on other scripts, the problem
> disappears. 
> 
> I know it sounds crazy, but non-modperl scripts sometimes don't get
> their POST data if I use modperl for other scripts.

Are you using a modperl auth handler anywhere?  If an
auth handler has been coded to use CGI.pm, it will consume 
the POST data and your cgi scripts won't ever get it.
 

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: APR::Poll support -- first cut

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

> in order to accept your code, it should be either posted here without any
> copyright notices in the post (which automatically makes it a public domain),
 

No, it doesn't:

  http://www.copyright.gov/fls/fl100.html

  ... Since the Berne Convention prohibits formal requirements that 
  affect the exercise and enjoyment of the copyright, the United States 
  changed its law on March 1, 1989 to make the use of a copyright notice 
  optional.

IMO a patch containing a copyright notice is problematic because
it's no longer clear the author intends for it to be treated as 
a typical contribution to the project.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[PATCH] Fix Apache::DBI cleanup when multiple database handles are used

[Joe Thomas]

This patch should make the cleanup handlers roll back all database handles
that have been used in a script, rather than just the last one connected.
Currently, $Idx is a file-scoped variable, and gets overwritten with each
call to Apache::DBI::connect.

I've made $Idx a lexical variable scoped to connect(), and pass it as a
parameter to cleanup().  This necessitated pushing a closure ("sub {
cleanup($Idx) }") onto the cleanup handlers.

The real reason I wrote this was that I have a DBD driver that aggregates
several database handles into one virtual handle.  It was calling
DBI->connect from inside its own connect method, and strange bugs started
popping up when it was run under Apache::DBI.  It turns out that the inner
connect() calls were causing $Idx to be overwritten, so the handle got
stored in the wrong slot in %Connected.

This patch makes Apache::DBI::connect reentrant, and my problem goes away.

Joe



DBI.pm.patch
Description: Binary data
-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] a little OT, problem finding libapr

[Joe Schaefer]

Carl Brewer <[EMAIL PROTECTED]> writes:

[...]

> Out of curiosity, is anyone working on docs for apreq2 for
> people in a hurry? :)  Ie: with simple examples in it?

Not that I am aware of; I think that makes you
the first volunteer :-).

May I suggest you add these to FAQ.pod instead of the
API docs?  There are plenty of examples in those 
already, and the neat thing is that almost all of 
them are tested to work as documented.

-- 
Joe Schaefer

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Apache::DBI patches

[Joe Thomas]

A couple days ago, I posted a patch that fixed what I think is a real bug in
Apache::DBI when a script uses more than one database handle:

http://mathforum.org/epigone/modperl/stroblangnerm

Basically, I removed $Idx as a file-scoped variable, because if a script
used more than one database handle, the initial value of $Idx would get
overwritten, and the first database handle would never get to the
cleanup/rollback routine.

Back in July 2003, Patrick Mulvany posted a more substantial patch that
ensures that database handles get restored to their expected state if, for
example, a script changes AutoCommit, and doesn't change it back:

http://mathforum.org/epigone/modperl/gripemneh

With Patrick's patch, the next user of the database handle won't see the
effects of the first script's fiddling with the AutoCommit property.

Both patches are working well for me, and I was surprised to see no
discussion of either on the mod_perl list.  Patrick's patch needed a small
change to work with mine, so I've taken the liberty of combining them in the
attached file.

I'm also cc'ing Ask, as I think this should be included in Apache::DBI.  Of
course, feedback from others is welcome.

Thanks,
Joe


combinedpatch
Description: Binary data
-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Tue, Sep 07, 2004 at 08:58:26AM -0400, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
> >>I'd put my $5.00 on APR being the cause of this problem. Mikhail, you
> >>will probably need to patch APR when you build Apache. Try this patch,
> >>which I am guessing will work on NetBSD:

I wasn't surprised this fails on OpenBSD but I am surprised it fails on
NetBSD.  Can you compile and run:

http://www.apache.org/~jorton/nonblock.c

and post the output.  (it would be useful if you could do this on
OpenBSD too, Ken, for verification)

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Tue, Sep 07, 2004 at 03:49:59PM -0400, Stas Bekman wrote:
> Ken Simpson wrote:
> >>>Ken, Stas, done as advised. The only test which is failing now (and was 
> >>>failing before) is:
> >>
> >>Mikhail, Ken, please submit that patch to dev /at/ apr.apache.org
> >>http://apr.apache.org/. Hopefully it'll get into 2.0.51 release. Or may 
> >>be it's too late.
> >
> >
> >The patch has already gone into APR CVS.
> 
> I thought that patch was only for OpenBSD. Is that not the case?

That's correct, this is currently fixed only for OpenBSD, and I'd prefer
to see the output of the test case on NetBSD to see why it fails there
before proceeding to use the same fix for that platform.

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Tue, Sep 07, 2004 at 08:25:03AM -0700, Ken Simpson wrote:
> > I wasn't surprised this fails on OpenBSD but I am surprised it fails on
> > NetBSD.  Can you compile and run:
> > 
> > http://www.apache.org/~jorton/nonblock.c
> > 
> > and post the output.  (it would be useful if you could do this on
> > OpenBSD too, Ken, for verification)
> 
> -bash-2.05b$ ./nonblock
> connect: Invalid argument

Thanks, I had not remembered the issue correctly...  The problem is that
getsockname() does not return the real port number for a socket bound to
an ephemeral port on OpenBSD.  So the apr_hints.m4 change is correct for
this issue since the autoconf test can't work.

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Thu, Sep 09, 2004 at 11:38:15AM +0400, [EMAIL PROTECTED] wrote:
> > I wasn't surprised this fails on OpenBSD but I am surprised it fails on
> > NetBSD.  Can you compile and run:
> > 
> > http://www.apache.org/~jorton/nonblock.c
> > 
> > and post the output.  (it would be useful if you could do this on
> > OpenBSD too, Ken, for verification)
> > 
> sorry for the dealy -- was away from my PC for a day 
> 
> k714% ./nonblock
> found port: 52984
> O_NONBLOCK is not set in the child.

This is rather confusing, since it means that apparently the test is
working OK, and O_NONBLOCK is *not* inherited across accept() on NetBSD,
which contradicts the behaviour you are seeing.


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

I can try and debug this, I've found a NetBSD machine and reproduced the
failure.  ./t/TEST -start-httpd doesn't work from the mod_perl test
suite, is there a way to get that working?

bash-2.05b$ ./t/TEST -start-httpd
/tmp/jorton12/root/bin/httpd -d /tmp/jorton12/mod_perl-1.99_16/t -f 
/tmp/jorton12/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2
using Apache/2.0.51-dev (prefork MPM)
 
waiting 120 seconds for server to start: .[Tue Sep 14 15:53:52 2004] 
[info] 27 Apache:: modules loaded
[Tue Sep 14 15:53:52 2004] [info] 7 APR:: modules loaded
[Tue Sep 14 15:53:52 2004] [info] base server + 20 vhosts ready to run 
tests
[Tue Sep 14 15:53:53 2004] [error] Can't locate 
ApacheTest/PerlModuleTest.pm in @INC (@INC contains: 
/tmp/jorton12/mod_perl-1.99_16/t/lib 
/tmp/jorton12/mod_perl-1.99_16/Apache-Test/lib 
/tmp/jorton12/mod_perl-1.99_16/t/response 
/tmp/jorton12/mod_perl-1.99_16/t/protocol 
/tmp/jorton12/mod_perl-1.99_16/t/preconnection 
/tmp/jorton12/mod_perl-1.99_16/t/hooks 
/tmp/jorton12/mod_perl-1.99_16/t/filter /tmp/jorton12/mod_perl-1.99_16/t 
/tmp/jorton12/mod_perl-1.99_16/t/htdocs/testdirective/main 
/tmp/jorton12/mod_perl-1.99_16/t/htdocs/testdirective/perlmodule-vh 
/tmp/jorton12/mod_perl-1.99_16/t/ 
/tmp/jorton12/mod_perl-1.99_16/t/lib/perl 
/tmp/jorton12/mod_perl-1.99_16/blib/lib 
/tmp/jorton12/mod_perl-1.99_16/blib/arch 
/usr/pkg/lib/perl5/site_perl/5.8.0/i386-netbsd 
/usr/pkg/lib/perl5/site_perl/5.8.0 /usr/pkg/lib/perl5/site_perl 
/usr/pkg/lib/perl5/5.8.0/i386-netbsd /usr/pkg/lib/perl5/5.8.0) at (eval 
60) line 3.\n
[Tue Sep 14 15:53:53 2004] [error] Can't load Perl module 
ApacheTest::PerlModuleTest for server localhost:8549, exiting...


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Thu, Sep 09, 2004 at 05:40:48PM +0400, [EMAIL PROTECTED] wrote:
> > > 
> > > k714% ./nonblock
> > > found port: 52984
> > > O_NONBLOCK is not set in the child.
> > 
> > This is rather confusing, since it means that apparently the test is
> > working OK, and O_NONBLOCK is *not* inherited across accept() on NetBSD,
> > which contradicts the behaviour you are seeing.
> > 
> same on netbsd-1.6.1
> 
> k133% ./nonblock
> found port: 65534
> O_NONBLOCK is not set in the child.
> k133%

Oh well, having found a NetBSD box to testd this myself, the NetBSD
fcntl() is being economical with the truth.  It doesn't return
O_NONBLOCK yet the socket really is non-blocking. I'll put in the
suggested apr_hints.m4 change.  fun fun

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Wed, Sep 15, 2004 at 05:15:05PM +1000, Carl Brewer wrote:
> Joe Orton wrote:
> 
> >Oh well, having found a NetBSD box to testd this myself, the NetBSD
> >fcntl() is being economical with the truth.  It doesn't return
> >O_NONBLOCK yet the socket really is non-blocking. I'll put in the
> >suggested apr_hints.m4 change.  fun fun
> 
> This may be worth bringing to the attention of the NetBSD core team,
> as there's a 2.0 release coming up pretty soon, it may be a
> bugfix worth including.

yah, http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26950

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Fri, Sep 17, 2004 at 04:15:23PM -0400, Stas Bekman wrote:
> So is that the right skip rule (hoping that 2.0.52 will fix NetBSD:
> 
> my $should_skip =
> ($^0 eq /^OpenBSD$/i && !need_min_apache_version('2.0.51')) ||
> ($^0 eq /^NetBSD$/i  && !need_min_apache_version('2.0.52'));

That logic is correct w.r.t the APR issue, yes.


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors

[Joe Orton]

On Wed, Sep 22, 2004 at 10:17:34PM -0400, Stas Bekman wrote:
> Joe, as 2.0.52 is about to be released. Can that fix for NetBSD applied to 
> the 0.9 trunch (and head) if it does the trick? Thanks.

It's been in both branches for a while so hopefully it will get picked
up, yep.

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Threaded MPM and performance (was: Re: Variables in memory.)

[Joe Schaefer]

Larry Leszczynski <[EMAIL PROTECTED]> writes:

[...]

> The above link mentions the memory benefits of having few perl intepreters
> among many threads e.g. if you have a mix of static and dynamic content.
> But it made me wonder what is the effect regarding the "spoonfeeding slow
> clients" scenario?

I've been trying to get httpd to include a patch for the worker mpm 
that will handle this nicely:

  http://marc.theaimsgroup.com/?t=10934643134&r=1&w=2
  http://marc.theaimsgroup.com/?t=10958788362&r=1&w=2

It's not quite ready for a production environment, but it'd 
really help if someone with a good "slow-client" test environment 
benchmarked it to see if it helps.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Threaded MPM and performance

[Joe Schaefer]

Stas Bekman <[EMAIL PROTECTED]> writes:

[...]

> It depends on many things. For example it's possible to have a simple filter
> written in C, which will accept all the data from the response handler
> and then spoonfeed the client, just like the proxy does.

Stas, related question: I was looking over the interpreter-pool stuff in 
modperl_interp.c and modperl_callback.c and it looks to me like each call
to modperl_callback_run_handlers grabs its own interpreter to use.  Do
you know if it's possible, within a single http request, for an auth
handler and a response handler to use two different perl interpreters?
It looks to me like it is possible.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] & Apache2: undefined symbol: PL_localizing

[Joe Orton]

On Mon, Oct 11, 2004 at 11:47:33PM +0200, MARTIN Pierre wrote:
> > Please do:
> > cd src/modules/perl/
> > rm mod_perl.so
> > make -f Makefile.modperl
> 
> Here we go:
> 
> /data/misc/mod_perl-1.99_16/src/modules/perl# rm mod_perl.so
> /data/misc/mod_perl-1.99_16/src/modules/perl# make -f Makefile.modperl
> rm -f mod_perl.so
> cc -shared -L/usr/local/lib \
...
> ags.lo modperl_xsinit.lo  -rdynamic  -L/usr/local/lib
> /usr/lib/perl/5.6.1/auto/D
> ynaLoader/DynaLoader.a -L/usr/lib/perl/5.6.1/CORE -lperl -ldl -lm -lc -lcryp
> t \
> -o mod_perl.so
> : mod_perl.so

This problem is probably caused by a bogus libperl.a on your system
somewhere.  What does:

ls -l /usr/lib/perl/5.6.1/CORE/libperl.* /usr/lib/libperl.* \
   /usr/local/lib/libperl.*

give? 

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] & Apache2: undefined symbol: PL_localizing

[Joe Orton]

On Wed, Oct 13, 2004 at 08:26:43AM -0400, Stas Bekman wrote:
> Joe Orton wrote:
> >This problem is probably caused by a bogus libperl.a on your system
> >somewhere.  What does:
> >
> >ls -l /usr/lib/perl/5.6.1/CORE/libperl.* /usr/lib/libperl.* \
> >   /usr/local/lib/libperl.*
> >
> >give? 
> 
> IMHO, it's libperl.so the linker is after, not libperl.a, since it's 
> -rdynamic -lperl.

-rdynamic is an obsolete gcc alias for -Wl,--export-dynamic, and has no
effect on whether the linker uses static or dynamically loaded libraries
for -l options.  (in fact it's completely redundant when linking a
shared object like mod_perl as far as I'm aware)

If -lperl was specified on the link line and ldd does not show a
dependency on libperl.so.N, then barring a complete linker fubar, it
must be the case that a libperl.a was linked statically.

joe


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] & Apache2: undefined symbol: PL_localizing

[Joe Orton]

On Wed, Oct 13, 2004 at 05:02:30PM -0400, Stas Bekman wrote:
> Joe Orton wrote:
> >If -lperl was specified on the link line and ldd does not show a
> >dependency on libperl.so.N, then barring a complete linker fubar, it
> >must be the case that a libperl.a was linked statically.
> 
> I doubt that this is the case, because I asked Martin to run nm on 
> mod_perl.so and perl symbols were unresolved. Please see:
> http://article.gmane.org/gmane.comp.apache.mod-perl/15266

Yes, I read the whole thread, this seems consistent with linking against
a bogus libperl.a on the system (maybe from a different version of Perl)
which doesn't define all the symbols which mod_perl needs.  That seems 
far more likely than the linker being so borked it ignores -l flags.

joe





-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: SOAP::Lite, libapreq not playing together?

[Joe Schaefer]

Ken Miller <[EMAIL PROTECTED]> writes:

[...]

> So, what's the solution to this?

Consider upgrading to libapreq2/mp2, or use Apache::args() instead
of Apache::Request::args().  The code in question *might* work with
libapreq1 if you replace $r->args with $r->SUPER::args, but I'm
not sure.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] Handler Order

[Joe Orton]

On Fri, Oct 08, 2004 at 02:42:49PM +0200, Torsten FÃrtsch wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> I know one can specify the handler invocation order of the request phases. But 
> how to do it?
> 
> My problem is, I want to know if a request came in over http or https in the 
> fixup phase. With mp1 I had configured by the LoadModule order that a 
> mod_perl handler was called after the mod_ssl handler. Since mod_ssl sets up 
> subprocess_env in the fixup phase I could check subprocess_env('HTTPS') in a 
> mod_perl fixup handler.
> 
> How can I define that my mod_perl fixup handler is to be called after the 
> mod_ssl fixup handler?
> 
> Or how can I access the SSL related stuff from mod_perl prior to the response 
> phase?

The best thing to do is to use the ssl_var_lookup hook which the C
interface to mod_ssl exports, or better yet, if using 2.0.51 or later,
the ssl_is_https hook.  This means you don't have to use "SSLOptions
+StdEnvVars" to get SSL variables via subprocess_env, which adds a lot
of overhead since you probably don't need most of them, and the hook
orderings don't matter.

You'd have to right Perl bindings for this first of course!

joe

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html