[mp2] retrieving the calling handler

how would i go about retrieving (mod_perl or otherwise) the name
of the immediate calling handler of the current handler being
executed?

i'm trying to do loop checking in which a given handler may need
to be executed as a result of multiple subrequests, but never back
to back.

e.g.:

# httpd.conf ... 

# mod_transform uses an output filter to trap the content of a response
# it lives at http://www.outoforder.cc/projects/apache/mod_transform/docs/
LoadModule transform_module modules/mod_transform.so

# Apache::MyStuff cleans up uri->filename stuff 
<Location /foo>
PerlTypeHandler Apache::MyStuff
AddOutputFilter XSLT .xml
</Location>

so, the scenario here is that mod_transform needs to subrequest its
external entities. these external entities need to be able to run
once through the type handler, but only once, as the type handler
will loop indefinitely. the timeline goes as such:

* request comes in from a browser, or possibly a subrequest.

* Apache::MyStuff examines uri.

Re: file upload problem

John Saylor wrote:
> hi
> 
> i'm trying to make this modperl upload handler work and it doesn't. it
> keeps giving me absolutely nothing for the file [but gives all the
> params and their values just fine].
> 
[...]

Does your form pass things using the appropiate enctype: multipart/form-data

Tom

Re: Creating a filter for all text/html files

Scott Gifford wrote:
> Hello,
> 
> [...]
>
> I've got it working right now, but I'd like it to know the
> Content-Type that Apache would use for a document, so I can decide
> whether to filter it and so I can send a correct Content-Type header.

$r->content_type should tell you that.

http://perl.apache.org/docs/2.0/api/Apache/RequestRec.html#C_content_type_

> I can try to guess the content-type from the filename (which is what
> I'm doing now), but I'd prefer not to re-implement Apache's system for
> deciding content types, and I'd also like it to Do The Right Thing for
> CGI/mod_perl scripts, where you can't tell by the filename what
> content-type they're going to output.

Yes, certainly a good idea not to do anything of the sort. Let Apache tell you
that.

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\ <at> (apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: Creating a filter for all text/html files

> I can try to guess the content-type from the filename (which is what
> I'm doing now), but I'd prefer not to re-implement Apache's system for
> deciding content types, and I'd also like it to Do The Right Thing for
> CGI/mod_perl scripts, where you can't tell by the filename what
> content-type they're going to output.

in addition to what philippe said, Apache::Clean for mp2 should prove as a
good example for you to follow:

  http://search.cpan.org/~geoff/Apache-Clean-2.00_4/

see also the two articles on perl.com that talk about this particular module:

  http://www.perl.com/pub/a/2003/04/17/filters.html
  http://www.perl.com/pub/a/2003/05/22/testing.html

HTH

--Geoff

Re: [mp2] retrieving the calling handler

Dorian Taylor wrote:
> how would i go about retrieving (mod_perl or otherwise) the name
> of the immediate calling handler of the current handler being
> executed?
> 
> i'm trying to do loop checking in which a given handler may need
> to be executed as a result of multiple subrequests, but never back
> to back.

There was someone with a similar problem just a while ago:

http://gossamer-threads.com/lists/modperl/modperl/77721

I believe it is relevant to your question.

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\ <at> (apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: Barrier to implementing web content compression in mod_perl

I'm surprised nobody has mentioned this yet on the list, but one approach 
I'd recommend is going to 2 separate apache servers. A light frontend one 
that does all the SSL/compression work, and a heavy backend mod_perl one.

http://modperlbook.org/html/ch12_01.html

This works fantastic for us, and avoids any of the issues of chained filters 
in the mod_perl process. The light weight servers can easily do the 
compression and SSL work and deal with clients on slow networks, leaving our 
mod_perl servers to do the actual processing. Even though we process 2M+ 
requests a day, we generally don't have more than 20 mod_perl httpd procs at 
any one time, while having 500-1000 frontend apache procs dealing with the 
slow network clients.

We personally use mod_accel and mod_deflate written by Igor Sysoev. Although 
most of the docs are in russian, we managed to get it working, and it's been 
one of those things that has "just worked" since day 1. Anytime we've had 
any technical issues, I've emailed Igor, and he's been fast and responsive 
to reply and help, and he knows his stuff!

http://sysoev.ru/en/

See the link at the bottom for our success story and compilation procedure.

Good luck.

Rob

Re: setting environment variables

Geoff,
    I ran into some weirdness in this area (on a Win XP machine running 
Apache 2.0.52)
that seemed to be related to using lowercase environment variable names. 
It looked as if
PerlSetEnv uppercased the variable names, whereas SetEnv just ignored 
vars with lower
case names.

Sounds weird I know, and I didn't pin it down exactly, but try uppercase 
variables and
see if this works for you.

Regards: Colin

Geoffrey Young wrote:

>Octavian Rasnita wrote:
>  
>
>>Hi,
>>
>>I have tried to put the following lines in httpd.conf:
>>
>>SetEnv user "gigel"
>>SetEnv pass "parola"
>>
>>Well, if I print the environment variables using a cgi script, they are
>>printed fine, but if I use MP, their values are not printed, and I can see
>>just a:

Memory Question

Re: make test failed on solaris 8

Tulan W. Hu wrote:
>>I'm not sure what went wrong, but there is nothing in the log. And there
>>must be something since you had 'Access Denied'
> 
> 
> Does it need to access on internet? I need to have a proxy setting to go
> out.

No, no, none of the tests require that.

>>Please do:
>>
>>t/TEST -clean
>>t/TEST -verbose t/protocol/pseudo_http.t t/apr/util.t

> t/protocol/pseudo_http....# connecting to localhost:8544

> # send: foobar
> # testing : banner
> # expected: Welcome to TestProtocol::pseudo_http
> # received: Access Denied
> not ok 5

So for some reason one of the AAA phases fail. Please apply this patch, run:

t/TEST -clean
t/TEST -verbose t/protocol/pseudo_http.t

and post only t/logs/error_log.

Index: t/protocol/TestProtocol/pseudo_http.pm
===================================================================
--- t/protocol/TestProtocol/pseudo_http.pm      (revision 148914)
+++ t/protocol/TestProtocol/pseudo_http.pm      (working copy)
 <at>  <at>  -84,6 +84,8  <at>  <at> 
      for my $method (qw(run_access_checker run_check_user_id
                         run_auth_checker)) {

+        warn "starting method: $method\n";
+
          my $rc = $r->$method();

          if ($rc != Apache::OK and $rc != Apache::DECLINED) {
 <at>  <at>  -98,8 +100,13  <at>  <at> 
              my $username = prompt($socket, "Login");
              my $password = prompt($socket, "Password");

+            warn "u/p: $username/$password\n";
+
              $r->set_basic_credentials($username, $password);
          }
+
+        warn "finished method: $method\n";
+
      }

      return Apache::OK;

> t/apr/util................1..4
> # Running under perl version 5.008006 for solaris
> # Current time local: Mon Jan 31 09:16:52 2005
> # Current time GMT:   Mon Jan 31 14:16:52 2005
> # Using Test.pm version 1.25
> # Using Apache/Test.pm version 1.21
> ok 1
> # crypt
> ok 2
> # sha1
> not ok 3

here the sha1 fails. it's strange because apparently the same test running 
outside of modperl (i.e. t/apr-ext/util.t) doesn't have this problem. Is 
that correct? Can you post the output of:

t/TEST -v t/apr-ext/util.t

--

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas <at> stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: setting environment variables

colin_e wrote:
> Geoff,
>    I ran into some weirdness in this area (on a Win XP machine running 
> Apache 2.0.52)
> that seemed to be related to using lowercase environment variable names. 
> It looked as if
> PerlSetEnv uppercased the variable names, whereas SetEnv just ignored 
> vars with lower
> case names.
> 
> Sounds weird I know, and I didn't pin it down exactly, but try uppercase 
> variables and
> see if this works for you.

That's probably due to the differences of how perl and Apache interpret 
environ on win32. mod_perl really calls perl's funcs to get the env. I'm 
sure if you try that on the command line (plain perl) you will see the 
same behavior. something like:

setenv foo bar (whatever it is on win32)
perl -le 'print $ENV{FOO}'

on unix that won't work, but on win32 it should print 'bar'.

I believe Randy has mentioned this before.

How does mp1 deals with that?

Randy?

--

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas <at> stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com