Re: possible issue in mod_perl 2.0.4 with respect to STDERR

2009-11-12 Thread Torsten Foertsch
On Thu 12 Nov 2009, Shibi NS wrote:
 Configuration error log is in my applications httpd config file is


 ErrorLog = '| rotatelogs \log\error_log 1M '

 But if print something on STDERR from mod_perl program , Say debug
 print (print STDERR DEBUG ;) this is going to \log\error_log
 instead of \log\error_log.NNN

 Is this is a mod perl issue or i am doing something wrong

I suspect this ErrorLog directive resides inside a VHost?

STDERR is bound to the programs notion of file descriptor 2 or whatever 
it is on windows, not to the ErrorLog.

If you want to write to a VHost's ErrorLog use $r-log co.

See also

http://www.gossamer-threads.com/lists/modperl/modperl/99241
http://www.gossamer-threads.com/lists/modperl/modperl/99219
http://www.gossamer-threads.com/lists/modperl/modperl/99504

In addition to what is said here
http://www.gossamer-threads.com/lists/modperl/modperl/99248#99248
another way to capture STDERR could be a PERLIO layer or to tie STDERR 
to something.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Storing config values in-memory between sessions

2009-10-29 Thread Torsten Foertsch
On Thu 29 Oct 2009, Mahesh Khambadkone wrote:
 As it seldom changes, we dont want to use a database for these
 'config values', yet need a way to retain in memory and dirty its'
 value from time to time.

Have a look at MMapDB which I have just uploaded to CPAN.

I wrote this module some time ago exactly for that case: configuration 
data that seldom changes. Before I have used BerkeleyDB. But that is a 
bit touchy when it comes to sudden process death. I wanted something 
simple, stable and fast. So an MMapDB database cannot be modified by a 
connected process because it is mapped read-only. Changing data means 
rewriting the database file and reconnect the new one. This also means 
the whole database is shared memory between all connected processes.

There is a tie() based interface. So, even dumping human readable data 
is simple:

perl -MMMapDB -MData::Dumper -e '
  print Dumper(MMapDB-new(filename=shift)-start-main_index);
' /etc/opt/TRANSCONFIG/transconfig.mmdb

And a more complicated but faster interface:

perl -MMMapDB -le '
  # open the DB
  my $db=MMapDB-new(filename=shift)-start;
  # get data record positions
  my @pos=$db-index_lookup($db-mainidx, qw!actn opi /svn!);
  # fetch a data item
  print $db-data_record($pos[0])-[2];
' /etc/opt/TRANSCONFIG/transconfig.mmdb

One even can store large values there and pass references to them around 
and thus avoid copying and mallocing that happens normally when you do 
$x=$y:

perl -MMMapDB -MDevel::Peek -e '
  my $db=MMapDB-new(filename=shift)-start;
  my @pos=$db-index_lookup($db-mainidx, qw!actn opi /svn!);
  # get a reference to the data item to avoid copying
  my $v=\$db-data_record($pos[0])-[2];
  print $$v, \n;
  Dump $$v
' /etc/opt/TRANSCONFIG/transconfig.mmdb
File: '/opt/svnbook'.$MATCHED_PATH_INFO
SV = PV(0x9d4b50) at 0x7c9248
  REFCNT = 1
  FLAGS = (POK,READONLY,pPOK)
  PV = 0x7f956388d240 File: '/opt/svnbook'.$MATCHED_PATH_INFO
  CUR = 39
  LEN = 0

You see $v points to a read-only variable. The PV pointer of this 
variable references the string inside the read-only mapped database 
file. Now you can do $x=$v and only the reference is copied.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Server hangs after 502 request

2009-10-26 Thread Torsten Foertsch
On Sat 24 Oct 2009, Rolf Schaufelberger wrote:
 Starting some weeks ago the server sometimes hangs with an out of  
 memory problem.

Assuming you are running on linux the following sysctls may help to find 
the culprit.

vm.overcommit_memory=2
vm.overcommit_ratio=90

By default (overcommit_memory=0) when a process needs more memory linux 
simply says okay here you are no matter if the memory is currently 
available or not. This is based on the assumption that most processes 
do not use all memory they allocate at all. Later on, when the process 
really accesses the memory a page fault is generated and linux only 
then allocates the memory for the process. But now it is too late to 
signal the process out-of-memory. So, linux somehow has to obtain 
memory no matter what. So, in short-of-memory conditions linux starts 
the OOM killer. It implements some heuristic that chooses some best 
fitting processes to be killed. These best fitting processes may be 
totally unrelated to the original problem.

I had once a case where a perl program processed mailbox files (using 
Mail::Box) on a box where a postgres database ran. Unfortunately 
Mail::Box reads in the whole mailbox file. Normally our mailbox files 
were about 1-10mb and the program had worked for years. But suddenly we 
had one of 1Gb. Instead of signaling out-of-memory to the perl process 
linux killed the postgres database.

Make sure you have enough swap space (at least the RAM size) before 
experimenting with those sysctls.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Custom INC per-directory

2009-10-21 Thread Torsten Foertsch
On Wed 21 Oct 2009, Alan Young wrote:
 http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_

Unfortunately the Parent option works only in vhosts. But I believe it 
could be hacked to work also for directory containers. Of course 
PerlPostReadRequest, PerlTranslation and PerlMapToStorage phases are 
handled by the main interpreter for the vhost. But just before the 
PerlHeaderParserHandler is called one could check if the rest of the 
request cycle is to be handled by a different interpreter and fetch one 
from a cache or instantiate a new one.

Of course the user would have to know what he is doing using this 
feature. For example setting a PerlResponseHandler where the handler 
routine is an anonymous sub in the translation phase would not work as 
expected.

An alternative would be to have modperl inspect the uri prior to 
PerlPostReadRequest and decide what interpreter to use based on it, 
similar to what ServerPath does. Then the same interpreter would handle 
all phases.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: is it possible get the deflate information in reuest object

2009-10-12 Thread Torsten Foertsch
On Mon 12 Oct 2009, Shibi NS wrote:
 LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%)
 %{User-agent}i' deflate
 CustomLog /var/log/httpd/deflate_log deflate

 Can I get the Input/Output and Ratio information in Apache2 Request
 object or PerlLogHandler ?

in a PerlLogHandler you should be able to read them as 
$r-notes-{ratio} etc.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Configuring virtual hosts on the fly

2009-10-12 Thread Torsten Foertsch
On Sun 11 Oct 2009, André Warnier wrote:
  I see some hooks in PerlTransHandler and PerlMapToStorageHandler
  that seem like they can almost do what I want, but I don't see how
  to set other virtual host parameters, like ServerAdmin

 http://perl.apache.org/docs/2.0/api/Apache2/ServerRec.html#C_server_a
dmin_

 , UseCanonicalName,

  etc.
 
  I'm just starting to work on this, and I thought I would see if
  anybody had tried anything similar before and had some suggestions
  for what to do, or what not to do.

 I have never tried this myself, but the mod_perl 2.x documentation
 contains some hints that leads to believe that it should be possible.

Some things could work this way, others definitely will not. For example 
you cannot create an IP based vhost on demand. You cannot create log 
files on the fly. Well, you can but you cannot create them as root as 
it is done during startup.

In general its not a good idea to mess with things that are not marked 
as applicable in directory context for the following reason. Firstly, 
you have to make sure to reset them when you request is done. See the 
implementation of $r-document_root for example. And secondly, in a 
threaded environment changing those values in one thread can affect the 
behavior of other requests in other threads because they are shared.

UseCanonicalName is applyable in directory context. So, you can safely 
set it via $r-add_config. It may however be useless to set it in a 
translation or map2storage handler because if you have a directory or 
location container or even a .htaccess file that sets the directive it 
overwrites anything set in a translation handler. Best phase to do that 
is probably fixup.

ServerAdmin is valid only in server config and virtual host context 
(http://httpd.apache.org/docs/2.2/mod/core.html#serveradmin). So I 
wouldn't mess with that. Better create custom error pages.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Threading inside a handler script

2009-10-03 Thread Torsten Foertsch
On Sat 03 Oct 2009, Elizabeth Mattijsen wrote:
  I believe what you're doing should work, but I don't use threads
  for anything.  I'd probably fork and put the results in a database
  table or file.

 If you like the threads API, you might want to take a look at the  
 forks module on CPAN.  It provides the threads API using fork(),
 and   hence does not have many of the problems that native Perl
 ithreads have.

Or Coro. I have never used it with modperl but I think it will work. It 
does not use kernel threads but implements perl stack switches. So, you 
have to watch out to avoid blocking operations. Similar to win 3.x 
multitasking or early UNIX threading approaches.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: user undef

2009-09-30 Thread Torsten Foertsch
On Wed 30 Sep 2009, Bernhard Janetzki wrote:
 Hello together,
 i'm trying basic authentication via

 ## apache2 config:
 Location /auth
   SetHandler perl-script
   PerlAuthenHandler DataExchange::AuthHandler
   #PerlResponseHandler ModPerl::Registry
   Options +ExecCGI
   PerlOptions +GlobalRequest

   AuthType Basic
   AuthName The Gate
   Require valid-user
 /Location


 ## Example script:

 package DataExchange::AuthHandler;

 use strict;
 use warnings;

 use Apache2::Access  ();
 use Apache2::RequestUtil ();

 use Apache2::Const -compile = qw(OK HTTP_UNAUTHORIZED);

 sub handler {
 my $r = shift;

 warn $r-user();

my $password = $r-get_basic_auth_pw;

have a look at
http://perl.apache.org/docs/2.0/api/Apache2/Access.html#C_get_basic_auth_pw_

get_basic_auth_pw returns a status and the password. Your code has to 
check that status before proceeding.

see also
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthenHandler

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: ModPerl::Registry and Error Documents

2009-09-29 Thread Torsten Foertsch
On Tue 29 Sep 2009, Andreas Mock wrote:
 after searching for a while without finding an answer to my question
 I hope you can help me,

 We're using mod_perl with ModPerl::Registry to have only a thin
 layer between apache and our perl scripts. So far so good.
 Now we want to produce error documents dynamically and thought
 this could be achieved by simply producing a normal html document
 and setting a status code  400.

 But it seems that the apache error handling jumps in as soon as
 the code is seen and the html document is not delivered to
 the client.

 My question: Which is an easy and correct way to produce
 ErrorDocuments while using ModPerl::Registry?

You have asked this question already 2 times before, on 17.09.09 12:13 
and 17.09.09 11:15. The first time I have answered it.

If my answer is not satisfying could you be so kind and explain why?

If you want it to work the way you anticipate it should and it does not 
then take a fresh copy from the SVN repository at 
http://svn.eu.apache.org/repos/asf/perl/modperl/trunk and provide a 
patch.

But please stop asking the same question again and again.

Glücklicherweise spreche ich die selbe Sprache wie Du. Also, Du hast 
diese Frage schon 2 Mal gestellt. Beim ersten Mal habe ich geantwortet.

Wenn Dir meine Antwort nicht gefällt, könntest Du bitte erklären, was Du 
daran auszusetzen hast?

Wenn modperl nicht so tut, wie Du denkst, es sollte, dann nimm einen 
frischen Checkout von 
http://svn.eu.apache.org/repos/asf/perl/modperl/trunk bau es nach 
Deinem Geschmack um und stelle einen Patch zur Verfügung. Das ist der 
beste/einzige Weg, die gewünschte Funktionalität in modperl zu kriegen.

Ich denke auch, daß es mit ParseHeaders und einer Status: NNN Zeile 
tun sollte. Solange ich aber nicht direkt vor dem Problem stehe oder 
nichts anderes zu tun habe, was nie passieren wird, werde ich das 
Problem nicht angehen. So ähnlich denken wohl auch die anderen 
Entwickler.

Bitte hör auf, ein und die selbe Frage immer wieder zu stellen.

Und übrigens, der Text in meiner Signatur ist ernst gemeint. Ich bin 
käuflich.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Updating cookies in header during request processing

2009-09-18 Thread Torsten Foertsch
On Fri 18 Sep 2009, Igor Chudov wrote:
 But how can I change the cookie AFTER I called $cgi-start_html?

As long as there is nothing sent out on the wire you can add headers. 
When the response header is gone you can't. start_html() only generates 
a string as far as  know. So it depends upon when this string is sent.

But with mod_perl you can circumvent even this limitation. Write a 
caching output filter.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: ModPerl::Registry and custom error documents

2009-09-17 Thread Torsten Foertsch
On Thu 17 Sep 2009, Andreas Mock wrote:
 How can we dynamically create own error documents without using
 the lower level mod_perl/apache api? Is there a simple way?
 How can we achieve that?

A very simple registry script:

#!/usr/bin/perl

use strict;

my $r=shift;

$r-status($r-args);
exit;

Then you can configure ErrorDocuments, e.g.

ErrorDocument 404 http://huhu.com
ErrorDocument 500 dumm gloffe

Now try it out:

A 404 will be translated into a redirect:

$ curl http://localhost/etest?404 -v
* About to connect() to localhost port 80 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 80 (#0)
 GET /etest?404 HTTP/1.1
 User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 
OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
 Host: localhost
 Accept: */*

 HTTP/1.1 302 Found
 Date: Thu, 17 Sep 2009 11:05:19 GMT
 Server: Apache/2.2.13 (Unix) proxy_html/3.0.1 mod_ssl/2.2.13 
OpenSSL/0.9.8h DAV/2 SVN/1.6.4 mod_apreq2-20090110/2.7.1 
mod_perl/2.0.5threading3 Perl/v5.10.0
 Location: http://huhu.com
 Content-Length: 199
 Content-Type: text/html; charset=iso-8859-1

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title302 Found/title
/headbody
h1Found/h1
pThe document has moved a href=http://huhu.com;here/a./p
/body/html
* Connection #0 to host localhost left intact
* Closing connection #0


a 403 sends the normal error page

$ curl http://localhost/etest?403 -v
* About to connect() to localhost port 80 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 80 (#0)
 GET /etest?403 HTTP/1.1
 User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 
OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
 Host: localhost
 Accept: */*

 HTTP/1.1 403 Forbidden
 Date: Thu, 17 Sep 2009 11:05:58 GMT
 Server: Apache/2.2.13 (Unix) proxy_html/3.0.1 mod_ssl/2.2.13 
OpenSSL/0.9.8h DAV/2 SVN/1.6.4 mod_apreq2-20090110/2.7.1 
mod_perl/2.0.5threading3 Perl/v5.10.0
 Content-Length: 207
 Content-Type: text/html; charset=iso-8859-1

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title403 Forbidden/title
/headbody
h1Forbidden/h1
pYou don't have permission to access /etest
on this server./p
/body/html
* Connection #0 to host localhost left intact
* Closing connection #0

and a 500 delivers a custom error message:

$ curl http://localhost/etest?500 -v
* About to connect() to localhost port 80 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 80 (#0)
 GET /etest?500 HTTP/1.1
 User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 
OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
 Host: localhost
 Accept: */*

 HTTP/1.1 500 Internal Server Error
 Date: Thu, 17 Sep 2009 11:09:19 GMT
 Server: Apache/2.2.13 (Unix) proxy_html/3.0.1 mod_ssl/2.2.13 
OpenSSL/0.9.8h DAV/2 SVN/1.6.4 mod_apreq2-20090110/2.7.1 
mod_perl/2.0.5threading3 Perl/v5.10.0
 Content-Length: 11
 Connection: close
 Content-Type: text/html; charset=iso-8859-1

* Closing connection #0
dumm gloffe

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Why people not using mod_perl

2009-09-17 Thread Torsten Foertsch
On Thu 17 Sep 2009, Kiran Kumar wrote:
 There is also Padre (http://padre.perlide.org/) , You can write
 plugins and customize to your needs, there are already lots of
 plugins available
  http://search.cpan.org/search?query=padre%3A%3Apluginmode=all

I have seen padre first time at the this year German perl workshop in 
February and tried it out a bit. What I miss is syntax highlighting and 
indentation for C, XS and Perl in one tool. Can padre handle this? Last 
time I looked it could not but that was half a year ago.

I am using Emacs for almost 20 years now but it lacks good XS support.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Ways to scale a mod_perl site

2009-09-17 Thread Torsten Foertsch
On Wed 16 Sep 2009, Igor Chudov wrote:
  I have very little static content. Even images are generated. My
  site generates images of math formulae such as (x-1)/(x+1) on the
  fly.,
 
  I can understand generating them on the fly for flexibility
  reasons, but I'd cache them, and serve them statically after that,
  rather than regenerate the images on every single request.  You can
  accomplish that in the app itself, or just by throwing a caching
  proxy in front of it (maybe you're already doing this with perlbal)

 I actually do cache generated pictures, I store them in a database
 table called 'bincache'. This way I do not have to compute and draw
 every image on the fly. If I have a picture in bincache, I serve it,
 and if I do not, I generate it and save it. That saves some CPU, but
 makes mysql work harder.

I'd go for Apache's mod_cache + mod_disk_cache. The only thing you have 
to do is to set cache control headers. Mod_cache is really fast b/c it 
skips almost all of the http request cycle. And in your case it takes 
load from the database. The request won't even hit mod_perl.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: changing apache process name?

2009-09-02 Thread Torsten Foertsch
On Tue 01 Sep 2009, Sebastiaan Hoogeveen wrote:
 Not sure if this would fix your problem, but you can just set $0 from
   within the mod_perl module to whatever you'd like to show up in the
 process list, just as with a regular perl script. It probably depends
 on the OS you're running whether this works as it should; I can
 confirm that it works on Linux.

This should work in mod_perl as well. Perl 5.8.0 had a bug that 
prevented it. Hence the Sys::Proctitle module.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: changing apache process name?

2009-09-01 Thread Torsten Foertsch
On Tue 01 Sep 2009, mcvella wrote:
 I am wondering if anyone knows if there is a way to configure what it
 shown as the running apache process name.  I am not sure if this is
 technically a mod_perl question.  The problem is that the process
 name is partially truncated, so we are unable to determine exactly
 what perl app is running for a given apache process.

 For example, here is one running apache process as seen in top:

 31122 www       16   0 76624  61m 6428 S    6  0.4   0:04.03
 /opt/myapp/www/cgi-perl/sig -f /opt/c2/preview/tmp/httpd.conf

 there is more to the perl app name than 'sig', (for example, it could
 be signal.pl or signoff.pl) but it is truncated.

 Is there any way to configure apache to show more characters in its
 process names?

It depends upon your operating system.

FreeBSD has a library function called setproctitle to do that as far as 
I know.

On Linux it can be achieved like this. The original argv and envp are 
laid out subsequently by the kernel. Normally a program accesses its 
argv only at startup and the original environment is copied and not 
used later on. But the argv pointer is where ps and top look for the 
command line. So there is a buffer of the size of all command line 
arguments plus all the environment that can be overwritten and thus 
used to show what you like in ps and top. The only problem is how to 
get the values of these pointers. This can be solved using a shared 
library. It may contain a function named _init() that is called when 
the lib is loaded. Fortunately it is passed argc, argv and envp as 
parameters. Now, you have all information to figure out the size of the 
argv and envp buffer and can overwrite it as you like.

This is what the libsetproctitle (http://lmgtfy.com/?q=libsetproctitle) 
library does.

I have once (at the time of perl 5.8.0) written a module Sys::Proctitle 
that uses (and bundles) this lib and also an Apache2::ShowStatus that 
uses Sys::Proctitle to show the current request in top. But since then 
I haven't touched these modules. So I don't know if they still work.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: mod_perl2 interactive startup

2009-08-26 Thread Torsten Foertsch
On Tue 25 Aug 2009, ama...@solutionsforprogress.com wrote:
 Unfortunately using restart_count does not address my issue.

 In the http.conf I have the following:
 ...
 PerlConfigRequire   conf/startup.pl
 ...

 My test startup.pl has this:

      our $INPUT;
      print STDERR Input:;
      $INPUT = STDIN;
      print STDERR you entered $INPUT;

 My issue is during the first start everything works as I need it to,
   Input: is printed out to the terminal and the script waits for
 input.

 The problem is for the automatic restart everything is tied to the
 log files. Everything printed to STDERR goes into the logs and a user
 cannot enter any input.

 For the restart how can I print messages and prompt for input?

Don't know if it actually works, but how about POSIX::dup2()ing 
STDERR/STDIN (or better opening /dev/tty and use this one for reading 
and writing) to well known file descriptors (say 1000, 1001) when 
restart_count==0. Then when restart_count0 you should be able to use 
them.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: getting $r and env to reflect external ports

2009-08-15 Thread Torsten Foertsch
On Sat 15 Aug 2009, Jonathan Swartz wrote:
 We've got a bunch of legacy code that uses $ENV{SCRIPT_URI},  
 $ENV{SERVER_PORT}, $r-server-port and the like to generate external
   redirects.

 This has worked fine til now, but now we are moving to a system where
   our external port != our internal port - the load balancer is going
 to forward ports 80 and ports 443 to non-secure ports 8080 and 8443
 (so that we can run httpd as a non-root user.) Unfortunately, the
 code mentioned above will then use the wrong (internal) ports in the
 redirects. If I were using Apache reverse proxy, ProxyPassReverse
 would take care of this, but I'm not.

 The legacy code is scattered in many files and will be difficult to  
 change. Thus I'm wondering if there's an easy way to get %ENV and $r
   to reflect the external ports, without going through and changing
 each port-related $ENV and $r value by hand.

 e.g. In the Apache code I see that the ENV vars are populated via  
 ap_get_server_port - is there a way for me to hook in early enough  
 that I can change this?

According to the docs the server port can also be set. But I think this is not 
a good idea.

The $r-server-port part can possibly be circumvented by reassigning a new 
function to the Apache2::ServerRec::port symbol at startup time. Try this in 
your startup.pl:

use Apache2::ServerRec ();
BEGIN {
  my $old=\Apache2::ServerRec::port;
  *Apache2::ServerRec::port=sub {
if( @_==1 ) {# read access
  my $port=$old-(@_);
  if( $port==8080 ) {
return 80;
  } elsif(...) {
...
  } else {
return $port;
  }
} else {
  return $old-(@_);
}
  };
}

As for the %ENV part this approach may work. Call $r-subprocess_env in void 
context without parameters somewhere before the response phase, e.g. fixup. 
This initializes the CGI variables in %ENV or rather $r-subprocess_env. Then 
use $r-subprocess_env to change what you need. The subsequent perl-script 
handler will know that the CGI variables are already set up and won't do it 
again. So your script should see the overridden values. That's the theory.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: disable input and output filters for subfolders

2009-08-01 Thread Torsten Foertsch
On Sat 01 Aug 2009, Mike Barborak wrote:
 Invalid per-directory PerlOption: InputFilter

 so it seems that while PerlOption is allowed at the directory level,
 the InputFilter and OutputFilter options are not. (i actually
 couldn't find a relevant section in the docs about that so i am
 unsure.)

This might quite be true.

 it is my preferred solution to be able to turn the filter off for
 particular directories via the conf file so it is my fading hope that
 i'm doing something wrong?

 if i am not then my plan of attack is to use PerlSetVar. then my conf
 file would look like so:

 Directory /var/www/vhosts/mydomain.com/httpdocs/test
        PerlSetVar EnableMyFilter false
 /Directory

 and my input and output filter handlers would look something like
 this:

 sub handler : FilterRequestHandler
 {
 my $f = shift;

 return Apache2::Const::DECLINED if $f-r-dir_config (
 'EnableMyFilter' ) eq 'false';

 ...
 }

 does that approach sound correct?

Almost, it would be better to have the filter remove itself on first 
invocation if it's not needed. A typical filter of mine looks like 
this:

  my $ctx=$f-ctx;

  unless( defined $ctx ) {
unless( check_conditions($f) ) {
  $f-remove;
  return Apache2::Const::DECLINED;
}
$f-ctx($ctx=[]);
$f-r-headers_out-unset('Content-Length');
  }
  ...

$f-ctx is undefined on first invocation. So, unless defined $ctx I can 
run checks that need to be done only once. If one of the conditions is 
not met the filter removes itself and returns DECLINED.

You'll have to place your PerlVar check instead of check_conditions.

 or is that i need to add an enabling / disabling filter into the
 filter chain in front of my filter that reads the PerlSetVar option
 and then either leaves my filter in the chain or uses something like
 $f-next-next...-remove to remove it?

No, this is only a last resort if you cannot change the filter itself.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: disable input and output filters for subfolders

2009-07-30 Thread Torsten Foertsch
On Wed 29 Jul 2009, Mike Barborak wrote:
 i have filters working correctly for a directory on my website. there
 is a subdirectory that i would like to not be passed through the
 filters. can i do this through the apache conf file or do i need to
 code this into my filters?

 here is my apache setup:

 PerlRequire /var/www/vhosts/mydomain.com/conf/seo_startup.pl
 PerlModule HTTPRequestFilter
 PerlModule HTMLFilter

 Directory /var/www/vhosts/mydomain.com/httpdocs
 PerlInputFilterHandler HTTPRequestFilter
 PerlOutputFilterHandler HTMLFilter
 /Directory

 grasping for straws, i tried to add this but it didn't work:

 Directory /var/www/vhosts/mydomain.com/httpdocs/test
 PerlInputFilterHandler
 PerlOutputFilterHandler
 /Directory

 is there magic to remove filters for a subdirectory or even disable
 mod_perl altogether?

A filter can remove itself on first invocation ($f-remove). It can also 
remove any filter further down the filter chain 
($f-next-next...-remove).

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: disable input and output filters for subfolders

2009-07-30 Thread Torsten Foertsch
On Thu 30 Jul 2009, Torsten Foertsch wrote:

Sorry, I hit return while one of my left hand fingers rested on the CTRL 
key and the MUA interpreted this as send mail now.

So, here comes the rest of what I wanted to say.

 On Wed 29 Jul 2009, Mike Barborak wrote:
  is there magic to remove filters for a subdirectory or even disable
  mod_perl altogether?

 A filter can remove itself on first invocation ($f-remove). It can
 also remove any filter further down the filter chain
 ($f-next-next...-remove).

So, you can write a simple filter that checks things and removes the 
next filter in the chain if necessary. Then you insert this filter 
right before the unwanted one.

You can also disable mod_perl for certain request phases:

http://perl.apache.org/docs/2.0/user/config/config.html#C_Perl_Handler_

or completely:

http://perl.apache.org/docs/2.0/user/config/config.html#C_Enable_

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Linux::Smaps on RHEL

2009-07-22 Thread Torsten Foertsch
On Wed 22 Jul 2009, Jonathan Swartz wrote:
 I'm running into the problem using Linux::Smaps on RHEL with an
 Apache   server on port 80. Namely, that the httpd child doesn't have
 permissions to look at the smaps file.

       Linux::Smaps: Cannot open /proc/20074/smaps: Permission denied
    or
       Linux::Smaps: Cannot open /proc/self/smaps: Permission denied

 I believe it is this bug:

      https://bugzilla.redhat.com/show_bug.cgi?id=322881

 Since the redhat folks don't seem to be in a hurry to fix this, I'm  
 wondering if anyone has discovered a workaround. (Other than, don't
   use RHEL - beyond my control. :))

If access is denied by the kernel there is only one solution, fix the 
kernel.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: rewriterule, location, and perlhandler

2009-07-22 Thread Torsten Foertsch
On Wed 22 Jul 2009, Adam Prime wrote:
 Eric Lease Morgan wrote:
  On Jul 22, 2009, at 12:05 AM, Adam Prime wrote:
 
  By first changing my Location directive to the following:
 
   Location /sandbox/semantic-web/
 SetHandler perl-script
 PerlHandler Apache2::Alex::SemanticWeb
   /Location
 
  And then changing my RewriteRule to this:
 
RewriteRule ^/etexts/id/(.*) /sandbox/semantic-web/?id=$1
  [passthrough]
 
  I eliminate the need to have a file on my file system.
 
  Thank you.  oss++ * mailing_lists++

 If you want, it's actually possible to take this even further and
 remove rewrite completely.

 Location /etexts/id/
SetHandler perl-script
PerlHandler Apache2::Alex::SemanticWeb
 /Location

 Then alter your handler's code to parse $r-uri and extract
 everything after $r-location.  (or you can use $r-path_info, if the
 /etexts/id/ actually exists in your document root).  That'll give you
 the same thing that rewrite is currently stuffing into your id
 argument.

Never use path_info unless you are very sure it is what you want. 
Path_info is made for CGI scripts where $r-filename points to the file 
containing the script.

The usage of path_info leads to action at a distance problems. Assume 
you have an empty directory DOCROOT/etexts/id and path_info s what you 
want. Later an administrator adds a file or subdirectory to that 
directory or removes the id directory. Suddenly path_info has changed 
but the handler and all libraries it uses are still the same.

substr($r-uri, length $r-location) is almost always what you need.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: trying to add header field using PerlInputFilterHandler to proxy packets

2009-06-30 Thread Torsten Foertsch
On Tue 30 Jun 2009, Brandon Allgood wrote:
 PerlInputFilterHandler company::AddHeader
  
 and I wrote the following example handler
  
 package company::AddHeader;
  
 use strict;
 use warnings;
  
 use Apache2::Filter ();
 use Apache2::RequestRec ();
 use APR::Table ();
  
 use Apache2::Const -compile = qw(OK DECLINED);
  
 my $debug = 1;
  
 sub handler {
   my $f = shift;
  
   # if we have already seen this do nothing
   return Apache2::Const::DECLINED if $f-ctx;
  
   # get headers
   my $headers_in = $f-r-headers_in();
  
   # add header field
   $headers_in-set(Message,Hi Mom);
   $f-r-headers_in($headers_in);
  
   if($debug)
   {
     open FILE, /tmp/out.log or die $!;
     foreach my $key (keys %{$headers_in})
     {
       print FILE $key = $headers_in-{$key}\n;
     }
     close FILE;
   }
  
   $f-ctx(1);
  
   return Apache2::Const::OK;
 }
 1;

 As you can see, if debugging is turned on the headers are written to
 the file /tmp/out.log.  The contents of out.log contains the new
 header, but the requests being forwarded by the proxy don't seem to
 be altered.  Why is the new header not being sent?

A request level input filter is called when the request body is read. 
mod_proxy does this obviously *after* sending the request header to the 
backend server. Hence, adding an input header at this time is too late.

Why do you want to do that in a filter? Why don't you add it in a 
request phase prior to response. Fixup would be a good place for 
example.

PerlFixupHandler sub {   \
  use Apache2::RequestRec;\
  use Apache2::Const -compile='DECLINED';\
  $_[0]-headers_in-{Message}='Hi, Mom'; \
  return Apache2::Const::DECLINED;\
}

Another word to your filter, did you know you can remove a filter on 
first invocation? This way you can avoid the useless

  return Apache2::Const::DECLINED if $f-ctx;

sub filter {
  my ($f)=...@_;
  # do something
  $f-remove;
  return Apache2::Const::DECLINED;
}

I haven't benchmarked it but I believe this is faster than return if 
$f-ctx. But it only makes a difference of course if the filter is 
called more than once.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c

2009-05-22 Thread Torsten Foertsch
On Fri 22 May 2009, Jeff Trawick wrote:
 Hmmm, after trying to use what seems like a cool feature, I find that
 mod_perl was never taught to use the Apache 2's mod_include plug-in
 interface.

AFAIK, that is provided by Geoff's CPAN module Apache::IncludeHook or 
so.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: executing PerlHandler after default_handler?

2009-05-13 Thread Torsten Foertsch
On Wed 13 May 2009, William T wrote:
 What I want to do is issue a redirect if the file that was requested
 is not on disk, and I don't want the extra stat due to an NFS mount.

How about ErrorDocument 404 /modperl/handler/uri?

http://httpd.apache.org/docs/2.2/mod/core.html#errordocument

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Pass variable

2009-05-05 Thread Torsten Foertsch
On Tue 05 May 2009, Idel Fuschini wrote:
 I am the owner of  Apache Mobile Filter project (
 https://sourceforge.net/projects/mobilefilter/).
 After my filter detect the UserAgent of a device I want to pass the
 capability to other applications (cgi, php or tomcat with mod_jk) in
 the same web server.
 How can I do that ?

$r-subprocess_env
$r-headers_in
$r-notes

depends on what the other apps understand. I think subprocess_env is 
best choice.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Pass variable

2009-05-05 Thread Torsten Foertsch
On Tue 05 May 2009, Idel Fuschini wrote:
 how can I read this variable from php and jsp application ?

subprocess_env manipulates environment variables. So, if your 
application can read them it fetches them from that place.

 I did in perl code:

 $r-subprocess_env(XXX = $value);

 In cgi I see something like:

 REDIRECT_XXX value

Somehow you managed to execute an internal redirect between the time 
your filter is invoked and the CGI script. Is there an ErrorDocument 
involved? Another way to get an internal redirect is a CGI script that 
prints these 2 headers:

Status: 200
Location: /new/url

Apache then copies all environment variables (subprocess_env) from the 
original request to the environment of the new (redirected) request 
with REDIRECT_ prepended to all names. That is why you see a 
REDIRECT_XXX variable.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Undefined subroutine error

2009-04-14 Thread Torsten Foertsch
On Tue 14 Apr 2009, Roberto C. Sánchez wrote:
 I am currently using the latter call everywhere and it is still
 generating the Undefined subroutine error.

Would it be possible to post your module? Perhaps you forgot 
the package declaration?

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: generic question on input filters

2009-04-09 Thread Torsten Foertsch
On Thu 09 Apr 2009, André Warnier wrote:
 Suspicion : I cannot read the content, and print nothing when I am
 called.  Instead of accumulating the content and process it all at
 once at the end, should I process it chunk by chunk ?

yes, as I said in my previous mail, do it chunkwise.

 Is it OK then when the Content-Length header is wrong (since I am
 changing the size of the data) ?

As long as your handler does not rely on it you can ignore the 
Content-Length header. In fact, a request can also be sumbitted 
in Transfer-Encoding: chunked which means there is no CL header.

The end of request body is determined by the HTTP_IN filter 
(ap_http_filter() in httpd/modules/http/http_filters.c) which is a 
protocol filter. That means it comes before your filter.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: generic question on input filters

2009-04-09 Thread Torsten Foertsch
On Thu 09 Apr 2009, André Warnier wrote:
 I have the impression that I am getting this Apache error :

 [Wed Apr 08 22:46:22 2009] [crit] [Wed Apr 08 22:46:22 2009] file
 http_filters.c, line 1324, assertion !bb)-list))-next ==
 (struct apr_bucket *)((char *)(((bb)-list)) - ((long) (((char *)
 struct apr_bucket*)((void *)0))-link))) - ((char *) ((void
 *)0)) failed [Wed Apr 08 22:46:22 2009] [notice] child pid 5518
 exit signal Aborted (6)

Perhaps it's easier to implement a brigade based filter since this comes
from here:

rv = ap_get_brigade(r-input_filters, bb, AP_MODE_READBYTES,
APR_BLOCK_READ, bufsiz);

...

/* If this fails, it means that a filter is written incorrectly and that
 * it needs to learn how to properly handle APR_BLOCK_READ requests by
 * returning data when requested.
 */
AP_DEBUG_ASSERT(!APR_BRIGADE_EMPTY(bb));

Meaning your filter hasn't written anything.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: generic question on input filters

2009-04-08 Thread Torsten Foertsch
On Wed 08 Apr 2009, André Warnier wrote:
 I want to write a mod_perl input filter, which essentially would
 replace some characters from form-posted input on the fly, before
 letting the request go to the real application.
 The requests are POST, with content encoded in one long string,
 URL-encoded. I am thinking of writing this as a FilterRequestHandler
 filter, grabbing the content, splitting it on , URL-decoding the
 so-splitted query parameters individually, then in the value
 performing the character substitutions, then re-URL-encoding the
 query parameters, re-joining them with , and essentially et voilà.

 Basically, the type shown here :
 http://perl.apache.org/docs/2.0/user/handlers/filters.html#toc_Stream
_oriented_Input_Filters

 Is the above a realistic view, or am I missing something essential ?

Remember the request can consist of multiple brigades. Each filter 
invocation gets one brigade. That means you have to be prepared to 
store some context (store the /[^;]*$/ part in $f-ctx). Don't try to 
read in the whole request. Operate on each part of it.

For example try the following PerlInputFilterHandler:

  sub handler {
my ($f)=...@_;

$f-print(\n###\n);
my $buf;
while($f-read($buf, 1024)) {
  $f-print(\n$buf\n);
  undef $buf;
}
$f-print(\n:::\n);
return Apache2::Const::OK;
  }

with this PerlResponseHandler:

  sub handler {
my ($r)=...@_;

$r-content_type('text/plain');
my $buf;
while($r-read($buf, 15000)) {
  $r-print($buf);
  undef $buf;
}

return Apache2::Const::OK;
  }

and feed it with more than 8000 bytes:

perl -e 'print xx1' | curl -qs -d @- http://localhost/iftest

You'll see multiple blocks wrapped in  ...  from the filter loop. 
But you'll also see 2 blocks of # ... :: that mark the 
filter invocations.

BTW, the buffer size in the response handler is that large because is 
must be able to store a whole brigade's content due to a modperl bug, 
see XXX: comment in modperl_request_read(). So, don't $f-print much 
in one filter invocation.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: sending all of stderr to a process

2009-04-06 Thread Torsten Foertsch
On Sun 05 Apr 2009, E R wrote:
 My concern is about what happens in this scenario:

 1. Set everything up (named pipe, logger process, etc.)
 2. Now suppose the logger process dies (it crashes or I need to
 restart it) 3. Any writes through existing connections to the named
 pipe will just fail, and I'll lose those writes.

 I'm pretty sure about #3, but I might be wrong.

A (named) pipe is a ring buffer within the kernel. A writer can write to 
it up to a certain level. Then it is full and the writer blocks or 
gets an EAGAIN for nonblocking writes.

So there is a certain period of time when the data resides in the kernel 
buffer. All that data is lost when the kernel panics, loses power or 
similar.

Then the reader reads a piece of data from the pipe and does something 
with it.

If that process crashes between reading the data from the pipe and 
finishing its processing that piece is lost.

So there are at least 2 periods of time when data can get lost. But is 
that all? It depends on your definition of sending to stderr. For 
example lets look at httpd. The event it wants to log happens at a 
certain point (in quotes because it is a short period in reality) in 
time. Before it goes out of stderr there is a period of time when a 
string is made from the event in ap_log_error(), log_error_core() or 
somewhere else. That perhaps requires some malloc()ing to extend a pool 
etc. And of course there can be a stray SIGKILL on its way to the 
process that arrives just in the moment before the formatted string 
hits stderr.

That means there is a period of time when the event that is to be logged 
has happend but has not arrived on stderr.

All I want to say here is you can't make 100% sure that every event that 
has to be logged is really logged. You can achieve quite a good level 
but never 100%.

The good thing about a named pipe is that it can be connected by 
unrelated processes. So if the reader dies only the piece of data it is 
currently processing is lost. The writer can still write until the pipe 
is full. So, have your reader restarted fast enough. That's why I 
mentioned /etc/inittab.

 Perhaps I can't do what I want to do at the application level and I
 need to go to the kernel level - like write my own device driver or
 something, especially since I want to capture all output sent through
 stderr (ie. from Apache and from mod_perl and from any XS modules.)

As I said before you can't achieve 100% even at kernel level. And 
imagine you'd want to write to a data base from kernel space. I don't 
say its impossible but you'd have to reimplement the whole protocol and 
the protocol specs may be not even published. Happy hacking!

On Linux the ErrorLog of the base server is always opened on file 
descriptor 2 that means stderr. So, a reader that reads this stream 
gets everything (under normal conditions) that Apache, Perl or any XS 
module writes to stderr.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: sending all of stderr to a process

2009-04-06 Thread Torsten Foertsch
On Mon 06 Apr 2009, André Warnier wrote:
 How does it work with Apache children/threads that may be acting as a
 VirtualHost's having their own ErrorLog ?
 My experience is that anything logged by mod_perl modules running
 in a VirtualHost using explicit warn() or $r-log_error() or
 $r-log-info() etc.. ends up in the VirtualHost's ErrorLog, but some
 run-time messages like Use of uninitialized value in concatenation
 (.) or string at .. end up in the main Apache error log.  How does
 that come about ?

$r or $s based logging goes to the VHosts ErrorLog, yes. But the 
original poster worried about all of STDERR come it from perl, xs or 
whereever else.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: sending all of stderr to a process

2009-04-05 Thread Torsten Foertsch
On Sat 04 Apr 2009, E R wrote:
 One operational issue with this is that if the logger process dies,
 existing httpd processes will get a SIGPIPE signal on subsequent
 writes. Restarting the logger process does not restore the lost
 connections.


 On Fri, Apr 3, 2009 at 12:38 PM, Torsten Foertsch

 torsten.foert...@gmx.net wrote:
  On Fri 03 Apr 2009, E R wrote:
  I want to send all error output to a process for specialized
  logging. I know that you can use CustomLog with a pipe. However,
  will that capture output from things like 'print STDERR ...' or if
  an XS module directly writes to stderr? I need that output to also
  go to my logging process.
 
  Does anyone know if there an Apache module which does this?
 
  Give a named pipe's name to ErrorLog outside any virtual host. Then
  have your process read from that pipe.

At least with prefork and worker MPMs apache ignores SIGPIPE:

httpd-2.2.11/server/mpm/prefork/prefork.c:406: (similar in worker.c)
#ifdef SIGPIPE
sa.sa_handler = SIG_IGN;
if (sigaction(SIGPIPE, sa, NULL)  0)
ap_log_error(APLOG_MARK, APLOG_WARNING, errno, ap_server_conf, 
sigaction(SIGPIPE));
#endif

And later on it does not check the return code when writing the log:

httpd-2.2.11/server/log.c:682:
apr_file_puts(errstr, logf);
apr_file_flush(logf);

Back in 1999-2000 apache had a reliability problem with piped loggers.
Ever since I log to named pipes.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: sending all of stderr to a process

2009-04-03 Thread Torsten Foertsch
On Fri 03 Apr 2009, E R wrote:
 I want to send all error output to a process for specialized logging.
 I know that you can use CustomLog with a pipe. However, will that
 capture output from things like 'print STDERR ...' or if an XS module
 directly writes to stderr? I need that output to also go to my
 logging process.

 Does anyone know if there an Apache module which does this?

Give a named pipe's name to ErrorLog outside any virtual host. Then have 
your process read from that pipe.

At shell level:

  mkfifo /path/to/PIPE
  your_program /path/to/PIPE

in httpd.conf:

  ErrorLog /path/to/PIPE

I'd very much recommend to monitor your_program and have it restarted 
automatically if it crashes. The simplest way to do that is to start it 
via /etc/inittab.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Help needed for mod_perl 1.31-rc6 and Apache::Bootstrap

2009-03-30 Thread Torsten Foertsch
On Sun 29 Mar 2009, Fred Moyer wrote:
 Need one more for a release

$ make test
cp lib/Apache/Bootstrap.pm blib/lib/Apache/Bootstrap.pm
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 
'blib/lib', 'blib/arch') 
t/*.t
t/00-load.t ... 1/11 # Testing Apache::Bootstrap 0.05-rc2, Perl 
5.01, /usr/bin/perl
Apache::Test version is 1.31, minimum version required is 1.32, tests 
will be skipped
t/00-load.t ... ok
t/pod-coverage.t .. ok
t/pod.t ... ok
All tests successful.
Files=3, Tests=13,  1 wallclock secs ( 0.04 usr  0.01 sys +  0.73 cusr  
0.06 csys =  0.84 CPU)
Result: PASS

This is Suse Linux 11.1.

Kernel:
Linux opi 2.6.27.19-3.2-default #1 SMP 2009-02-25 15:40:44 +0100 x86_64 
x86_64 x86_64 GNU/Linux

mod_perl: the current threading branch with all patches for trunk 
merged.

The one thing that puzzles me is Apache::Test 1.32. My current copy of 
trunk shows:

$ svn info clean-trunk/Apache-Test/lib/Apache/Test.pm
Path: clean-trunk/Apache-Test/lib/Apache/Test.pm
Name: Test.pm
URL: 
https://svn.apache.org/repos/asf/perl/Apache-Test/trunk/lib/Apache/Test.pm
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 759858
Node Kind: file
Schedule: normal
Last Changed Author: gozer
Last Changed Rev: 607695
Last Changed Date: 2007-12-31 09:00:09 +0100 (Mon, 31 Dec 2007)
Text Last Updated: 2008-09-30 09:52:57 +0200 (Tue, 30 Sep 2008)
Checksum: 61e9675a4f820b7792c2f8313dd3d97c

And that file contains:

$VERSION = '1.31';

What did I miss?

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: who's putting that pre tag in the output...?

2009-03-23 Thread Torsten Foertsch
On Mon 23 Mar 2009, Iosif Fettich wrote:
 So it seems to be very, very easy. Still, when using the above
 receipt like
      RewriteEngine on
      RewriteCond   %{REQUEST_URI}   !-U
      RewriteRule   ^\/(.+)          http://OLDDOMAIN.COM/$1 [QSA,P]

The engine tries to resolve the request uri with a subrequest. Hence it 
goes through this rule twice. Try to add NS (no subrequest) to the 
flags [QSA,P,NS].

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: who's putting that pre tag in the output...?

2009-03-23 Thread Torsten Foertsch
On Mon 23 Mar 2009, Iosif Fettich wrote:
 Or is the [P]roxy flag not working as it should or as I expect it to
 ? It seems to work fine for the subrequest (status=200) ...?

This is exactly the problem. The 404 is normally generated in the 
response phase from the default response handler. The subreq lookup 
won't check that. It does not run the subreq but only checks if after 
fixup there is still no error.

So the simplest solution for you would be an ErrorDocument I think.

Something like this:

ErrorDocument 404 /-/404  - put an url here you are not using otherwise
RewriteRule ^/-/404 http://...%{REDIRECT_URI} [P]

Write a simple printenv and activate it as ErrorDocument first to get 
the right environment variable names (not sure if it is REDIRECT_URI). 
If you use mod_include that would be

  !--#printenv --

in an .shtml file.

This solution should work for GET/HEAD. POST requests are still a 
problem. If you use them we'll make it work without ErrorDocument. BTW, 
why don't you use the file lookup (-f). That is much easier. Is your 
uri-file mapping so complicated?

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


to the mailing list admin

2009-03-23 Thread Torsten Foertsch
Hi,

each of my last mailings to the list was answered by the following 
failure notice:

-

The following message to sbirl+excha...@concept.temple.edu was 
undeliverable.
The reason for the problem:
5.1.0 - Unknown address error 550-'5.7.1 torsten.foert...@gmx.net... 
Access denied'

-

Please remove this recipient from the list.

Thanks,
Torsten


Re: who's putting that pre tag in the output...?

2009-03-23 Thread Torsten Foertsch
On Mon 23 Mar 2009, Iosif Fettich wrote:
 Using the (obvious...!) REDIRECT_URL as you suggested works! :)

An ErrorDocument is an internal redirect. These REDIRECT_... environment 
variables are copied from the previous ($r-prev) request's 
$r-subprocess_env just by copying everything and prepending REDIRECT_ 
to each key. So if the original request has an environment variable 
named REQUEST_URI the error document should have a 
REDIRECT_REQUEST_URI, see rename_original_env() in 
httpd-x.y/modules/http/http_request.c.

Since REQUEST_URI is the standard CGI environment variable (see 
ap_add_cgi_vars() httpd-x.y/server/util_script.c) I'd take 
REDIRECT_REQUEST_URI.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: generated report (was Re: mp2 hangs when running make test)

2009-03-21 Thread Torsten Foertsch
On Sat 21 Mar 2009, Oliver Block wrote:
 *** mod_perl version 2.04

And how about the current development version?

I use a self compiled apache 2.2.11 plus 
http://svn.apache.org/repos/asf/perl/modperl/branches/threading/ with 
Suse 11.1. I think you are at 11.0?

If you like I can send you the SRPMs or at least the spec files.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: mp2 hangs when running make test

2009-03-20 Thread Torsten Foertsch
On Fri 20 Mar 2009, Oliver Block wrote:
 [warning] the client side drops 'root' permissions and becomes
 'nobody'

not sure, but I'd retry the complete build/test (beginning from 
extracting the TAR) without superuser privileges.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Capturing STDERR for use in log handler

2009-03-18 Thread Torsten Foertsch
On Tue 17 Mar 2009, Tom Spencer wrote:
 So far so good, it adds the information I've got to the database
 quite nicely.  But the one more thing I really need is all the STDERR
 that was generated while processing the request.  Recipe 6.10
 provides a method for outputting STDERR to a different file but I'd
 like to grab it and put it into my database.

First thing, you have to specify your understanding of all the STDERR 
in more detail. Is it

1) the warn and die output
2) all that perl writes to STDERR
3) something that XS modules or rather libraries used by XS modules 
write to filedescriptor 2
4) the stuff that apache logs to the virtual hosts errorlog

Here are some ideas how to solve these problems:

1) set $SIG{__WARN__} and $SIG{__DIE__} or implement CORE::GLOBAL::warn 
and CORE::GLOBAL::die

2) reopen STDERR to a memory filehandle, eg:
perl -Mstrict -e '
  # list our open fds to see what is going on
  system ls -l /proc/$$/fd;
  # save fd2 as SAVEERR
  open SAVEERR, STDERR or die Cannot dup: $!;
  close STDERR;
  # make sure that nobody else can open fd2 by chance
  open my $acquirefd2, , /dev/null or die acquire: $!;
  # check it
  system ls -l /proc/$$/fd;
  my $err;
  # open memory filehandle
  open STDERR, , \$err or die open: $!;
  # this output must not differ from the previous
  system ls -l /proc/$$/fd;
  # some printout to STDERR and a warning
  # nothing appears on the terminal
  print STDERR print to STDERR\n;
  warn warning;
  # print the error output to STDOUT surrounded by 
  print $err\n;
  close STDERR;
  system ls -l /proc/$$/fd;
  # release fd2
  close $acquirefd2;
  # redirect STDERR to the original fd2
  open STDERR, SAVEERR or die restore: $!;
  close SAVEERR;
  # check it
  system ls -l /proc/$$/fd;
  # these will appear on the terminal
  print STDERR print to STDERR\n;
  warn warning;
'

This is what I see (a bit commented):
total 0
lrwx-- 1 r2 users 64 2009-03-18 12:32 0 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 1 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 12 - socket:[12916]
lrwx-- 1 r2 users 64 2009-03-18 12:32 13 - socket:[12917]
# fd2 points to my terminal
lrwx-- 1 r2 users 64 2009-03-18 12:32 2 - /dev/pts/9
lr-x-- 1 r2 users 64 2009-03-18 12:32 3 - pipe:[10303]
l-wx-- 1 r2 users 64 2009-03-18 12:32 4 - pipe:[10303]
lr-x-- 1 r2 users 64 2009-03-18 12:32 5 - pipe:[31529]
lrwx-- 1 r2 users 64 2009-03-18 12:32 7 - socket:[12899]
total 0
lrwx-- 1 r2 users 64 2009-03-18 12:32 0 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 1 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 12 - socket:[12916]
lrwx-- 1 r2 users 64 2009-03-18 12:32 13 - socket:[12917]
# now it points to /dev/null
lrwx-- 1 r2 users 64 2009-03-18 12:32 2 - /dev/null
lr-x-- 1 r2 users 64 2009-03-18 12:32 3 - pipe:[10303]
l-wx-- 1 r2 users 64 2009-03-18 12:32 4 - pipe:[10303]
# but fd5 (SAVEERR) points to my terminal
lr-x-- 1 r2 users 64 2009-03-18 12:32 5 - /dev/pts/9
lr-x-- 1 r2 users 64 2009-03-18 12:32 6 - pipe:[31546]
lrwx-- 1 r2 users 64 2009-03-18 12:32 7 - socket:[12899]
total 0
lrwx-- 1 r2 users 64 2009-03-18 12:32 0 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 1 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 12 - socket:[12916]
lrwx-- 1 r2 users 64 2009-03-18 12:32 13 - socket:[12917]
lrwx-- 1 r2 users 64 2009-03-18 12:32 2 - /dev/null
lr-x-- 1 r2 users 64 2009-03-18 12:32 3 - pipe:[10303]
l-wx-- 1 r2 users 64 2009-03-18 12:32 4 - pipe:[10303]
lr-x-- 1 r2 users 64 2009-03-18 12:32 5 - /dev/pts/9
lr-x-- 1 r2 users 64 2009-03-18 12:32 6 - pipe:[31554]
lrwx-- 1 r2 users 64 2009-03-18 12:32 7 - socket:[12899]
# the framed output
print to STDERR
warning at -e line 19.

total 0
lrwx-- 1 r2 users 64 2009-03-18 12:32 0 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 1 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 12 - socket:[12916]
lrwx-- 1 r2 users 64 2009-03-18 12:32 13 - socket:[12917]
# still the same: fd2 points to /dev/null, fd5 to my terminal
lrwx-- 1 r2 users 64 2009-03-18 12:32 2 - /dev/null
lr-x-- 1 r2 users 64 2009-03-18 12:32 3 - pipe:[10303]
l-wx-- 1 r2 users 64 2009-03-18 12:32 4 - pipe:[10303]
lr-x-- 1 r2 users 64 2009-03-18 12:32 5 - /dev/pts/9
lr-x-- 1 r2 users 64 2009-03-18 12:32 6 - pipe:[31561]
lrwx-- 1 r2 users 64 2009-03-18 12:32 7 - socket:[12899]
total 0
lrwx-- 1 r2 users 64 2009-03-18 12:32 0 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 1 - /dev/pts/9
lrwx-- 1 r2 users 64 2009-03-18 12:32 12 - socket:[12916]
lrwx-- 1 r2 users 64 2009-03-18 12:32 13 - socket:[12917]
# here it is reverted, fd2 is the terminal, fd5 is something else
# (due to the ls command)
lrwx-- 1 r2 users 64 2009-03-18 12:32 2 - /dev/pts/9
lr-x-- 1 r2 users 64 2009-03-18 12:32 3 - pipe:[10303]
l-wx-- 1 r2 users 64 2009-03-18 12:32 4 - pipe:[10303]
lr-x-- 1 r2 users 64 2009-03-18 12:32 5 

BerkeleyDB solution

2009-03-10 Thread Torsten Foertsch
Hi,

this is not a problem but a solution. I know some of you use the 
BerkeleyDB module to store data. Recently I have tried to use UTF8 keys 
and failed. When reading back keys I sometimes got character strings 
sometimes octet strings. I had used the following 2 filters to ensure 
the data in the database is octet strings and the data I get back are 
character strings:

  $db-filter_fetch_key(sub { $_=Encode::decode('utf8', $_) });
  $db-filter_store_key(sub { $_=Encode::encode('utf8', $_) });

The problem is BerkeleyDB doesn't reset the UTF8 bit when storing data 
to @_ variables as in c_get() or db_get(). One possible solution is

  $db-filter_fetch_key(sub {
Encode::_utf8_off($_);
$_=Encode::decode('utf8', $_);
  });

The other/better one is to fix it in BerkeleyDB.xs. This is what the 
attached patch does. I have sent it to the author, Paul Marquess. Here 
is his reply:

On Tue 10 Mar 2009, Paul Marquess wrote:
 Your patch looks fine and should be ok to include in my development
 copy without any changes.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
--- BerkeleyDB.xs~	2009-02-18 21:31:46.0 +0100
+++ BerkeleyDB.xs	2009-03-06 14:38:04.0 +0100
@@ -430,7 +430,10 @@
 #define getInnerObject(x) ((SV*)SvRV(sv))
 #endif
 
-#define my_sv_setpvn(sv, d, s) (s ? sv_setpvn(sv, d, s) : sv_setpv(sv, ) )
+#define my_sv_setpvn(sv, d, s) do { \
+ s ? sv_setpvn(sv, d, s) : sv_setpv(sv, ); \
+ SvUTF8_off(sv); \
+   } while(0)
 
 #define GetValue_iv(h,k) (((sv = readHash(h, k))  sv != PL_sv_undef) \
 ? SvIV(sv) : 0)


Re: PerlConfigRequire and die

2009-02-28 Thread Torsten Foertsch
On Thu 26 Feb 2009, Clinton Gormley wrote:
  Why don't you do that in a Perl block?

 How is this different from doing it in the startup.pl file?  

Yes, I see, the 2nd run of the Perl code doesn't have STDERR either. 
So, you can open a startup logfile in perl and override 
CORE::GLOBAL::warn/die or install a $SIG{__WARN__/__DIE__} handler. Or 
even open that logfile at start of your startup.pl on file descriptor 2 
and close it at the end.

Perl
use Apache2::ServerUtil;

if( Apache2::ServerUtil::restart_count1 ) {
  open my $olderr, '', \*STDERR;
  close STDERR;
  open STDERR, '', '/tmp/myerr';

  # initialize your app here
  warn huhu;
  print STDERR haha;
  # end of init

  close STDERR;
  open STDERR, '', $olderr;
}
/Perl

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: PerlConfigRequire and die

2009-02-26 Thread Torsten Foertsch
On Thu 26 Feb 2009, Clinton Gormley wrote:
   Is there any way I can:
    - cause the error to be reported properly
    - force apache not to start
 
   eval {load_application(); 1} || do { warn $@; die };

 Unfortunately, no.  That still just dies with the obscure error
 message. It seems that STDERR only gets flushed in a later stage of
 the startup process.

 What I was thinking was, could there be some way of saying:

 eval { load_application();1}
   || do {
           warn $@;
           force_apache_to_quit_startup_once_stderr_flushed();
      }

Why don't you do that in a Perl block?

Be aware that this code is executed twice at startup. Check 
Apache2::ServerUtil::restart_count to prevent that.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: What can a child_init do?

2009-02-19 Thread Torsten Foertsch
On Thu 19 Feb 2009, cr...@animalhead.com wrote:
 Is there anything a mod_perl2 child_init phase can do to call
 attention to a problem?

 I moved a block of code from a post_config handler to a new
 child_init handler, without thinking much about the niceties of the
 move.  The code contained a couple of 'die' statements, which I trust
 would prevent an Apache startup if executed in a post config handler.

 Q1: WOULD 'DIE' IN A POST_CONFIG HANDLER ABORT AN
 APACHE2 STARTUP?

yes. Place the following line in your httpd.conf:

PerlPostConfigHandler sub {die q{huhu}}

and you'll see something like this in your error log:

[Thu Feb 19 08:51:21 2009] [error] huhu at (eval 
50) line 1.\n
Configuration Failed

and of course no running httpd.

 In the child_init handler, an executed 'die' did nothing noticeable.
 Specifically the message did not end up in the error_log.  In the
 mod_perl2 doc pages, child_init is described as being 'of type void',
 which another page says means that the return value doesn't matter.

 I will change the 'die' to a '$s-log_error', and return the
 nastiest- sounding Apache return code I can find, in hopes that some
 future Apache might notice it.

 Q2:  IS THERE ANYTHING A CHILD_INIT PHASE CAN DO TO
 ABORT ITS CHILD PROCESS, AND THUS CALL ATTENTION
 TO A SERIOUS PROBLEM?

PerlChildInitHandler sub {warn q{about to commit suicide}; kill 9, $$}

or

PerlChildInitHandler sub {warn q{exiting now}; CORE::exit -1}

But you should not need that. Because when apache needs another worker 
it will start one (or more). If they exit immediately apache will keep 
starting new ones.

Also, such things are bad for your users experience. The server accepts 
the connection but doesn't respond. The request times out without 
receiving a single byte. I think it's better to serve at least one 
request and inform the user about temporary problems. You can ask the 
current worker to die when the current request is done by 
$r-child_terminate (or was it terminate_child?).

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Alias and PerlOutputFilterHandler in virtual host configuration

2009-02-15 Thread Torsten Foertsch
On Sun 15 Feb 2009, Roger Munk wrote:
 I have the following directives in my sites-available/default
 configuration:

        DocumentRoot /var/www/
        Alias /portal/ /var/www/drupal6/
        PerlRequire /etc/apache2/ModPerl/TE/ST.pm
         Location /portal/
             SetHandler modperl
             PerlOutputFilterHandler TE::ST
         /Location

 When the SetHandler and PerlOutputFilterHandler are commented out,
 the redirection from /portal to /var/www/drupal6 works correctly.
 However, when the SetHandler and PerlOutputFilterHander are enabled I
 get the following error messages:


 [Mon Feb 16 22:43:40 2009] [error] [client 192.168.1.2] Attempt to
 serve directory: /var/www/drupal6/, referer: http://10.0.0.1/portal/
 [Mon Feb 16 22:43:40 2009] [error] [client 192.168.1.2] script
 '/var/www/index.php' not found or unable to stat, referer:
 http://10.0.0.1/portal/

 Why would the SetHandler and PerlOutputFilterHandler stop the Alias
 directive from working correctly?

It does not. You see the first message? That is the result of the alias. 
The thing that confuses me is what do you want to achieve 
by SetHandler modperl but leaving out the PerlResponseHandler?

If your page is generated by php and you only want to postprocess it on 
its way out then drop the SetHandler. The PerlOutputFilterHandler does 
not need a SetHandler modperl.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Alias and PerlOutputFilterHandler in virtual host configuration

2009-02-15 Thread Torsten Foertsch
On Sun 15 Feb 2009, Roger Munk wrote:
 On Sun, Feb 15, 2009 at 5:12 PM, André Warnier a...@ice-sa.com wrote:
  see http://perl.apache.org/docs/2.0/api/APR/Table.html#C_get_
  (you only get the first one this way)
  my @cookies = $f-r-headers_out-get(Set-Cookie);
  would get you an array with both.

 Thanks, when I tried receiving the cookies in an array, using the
 code below, I only see the second cookie now in the output. Since
 both cookies are set with seperate Set-Cookie headers are they
 getting overwritten at some point, or is there a problem with my
 code?

     unless ($f-ctx)
     {
         my @Cookies = $f-r-headers_out-get(Set-Cookie);

         foreach my $Cookie (@Cookies)
         {
             $Cookie =~ s/expires.*GMT\;//g;
             $f-r-headers_out-set(Set-Cookie = $Cookie);
         }
         $f-ctx(1);
     }

I am about to say RTFM but being polite: Please read the documentation 
mentioned above more thouroughly. APR::Table provides an add method. 
And before you ask your next question How can I get rid of the 
original cookies? read that piece again, ;-)

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Checking a webserver

2009-01-28 Thread Torsten Foertsch
On Wed 28 Jan 2009, André Warnier wrote:
 I am looking for a debugging tool that would be able to repeatedly
 issue HTTP requests to one or more URLs, and log any errors.
  Preferably in Perl, and it must run on a Windows workstation.

Don't know about windows and its not perl but I use ab (comes with 
httpd) and flood:

http://httpd.apache.org/test/flood/

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: PerlSetVar behaviour within Limit directive

2009-01-23 Thread Torsten Foertsch
On Fri 23 Jan 2009, Pat Downey wrote:
   Limit GET
     PerlSetVar CrowdAllowedGroups reader,writer
     Require valid-user
   /Limit
   LimitExcept GET
     PerlSetVar CrowdAllowedGroups writer
     Require valid-user
   /LimitExcept
 /LocationMatch

 What I'd like is for members of the reader or writer groups to have
 GET access and only members of the writer group to have everything
 else (mainly for POST) access.

 The problem seems to be that the 'PerlSetVar CrowdAllowedGroups
 writer' is overwriting the
 'PerlSetVar CrowdAllowedGroups reader,writer' call for all requests,
 not just the method that I'm trying to limit each setting to.

Then, how about

  PerlSetVar CrowdAllowedGroups reader,writer
  Require valid-user
  LimitExcept GET
PerlSetVar CrowdAllowedGroups writer
  /LimitExcept


Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Initializing Sleepycat::DbXml (Berkeley, Oracle) objects in startup.pl

2009-01-19 Thread Torsten Foertsch
On Sun 18 Jan 2009, Michael Ludwig wrote:
  From perldoc perlthrtut: In this model each thread runs in its own
 Perl interpreter, and any data sharing between threads must be
 explicit. This does not sound to me as if there is a significant
 advantage over spawning child processes, at least not on UNIX.

 Hmm. Not sure what to make of this threaded Perl.

In fact, it is worse than fork()ing off unix processes because the 
interpreter data is completely copied while a new interpreter is 
created. On the other hand a forked process copies only those pages 
that are written to.

I haven't used Sleepycat::DbXml but I use BerkeleyDB in production with 
prefork, see Apache2::Translation on CPAN. What I have learned is, you 
can't open the BDB env in the parent apache. When I wrote that piece I 
also had problems when I opened the env in the parent and then closed 
it before forking children. Perhaps they are gone in a newer version.

I think with prefork opening the env in a ChildInit handler should work. 
I ended up with the connect-at-first-usage approach

  unless( $connected ) {
connect();
$connected=1;
  }

because I test almost all my modules also with a threaded MPM and the 
ChildInit hook is run once per process not once per Perl interpreter.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Initializing Sleepycat::DbXml (Berkeley, Oracle) objects in startup.pl

2009-01-19 Thread Torsten Foertsch
On Mon 19 Jan 2009, Michael Ludwig wrote:
  In fact, it is worse than fork()ing off unix processes because the
  interpreter data is completely copied while a new interpreter is
  created. On the other hand a forked process copies only those pages
  that are written to.

 Thanks. If I'm understanding correctly and this is true (and not
 considering SEGVs), the total memory cost for a mod_perl on a worker
 MPM should outweigh that for mod_perl on a prefork MPM, which seems
 to not be aligned with what Craig has observed.

Of course it depends on your setup. If you configure only a small number 
of interpreters then the overall memory footprint can be lower then 
with prefork where each process runs its own interpreter. But the 
effect of the copied interpreters outweighs this very soon.

Measuring memory consumption on Linux is not simple. You can't simply 
add up all RSS or VSZ figures or something like this. I know of 2 
approaches that work more or less well.

1) call mlockall in the parent and then use /proc/PID/smaps (or 
Linux::Smaps) to measure shared memory

2) take a system with enough RAM and nothing else to do, start apache 
with different numbers of children and watch the free memory with 
vmstat while doing so. Then you can estimate the amount of memory that 
is consumed by one apache process. See the attached picture for 
example.

 In order to be on the safe side as far as Berkeley DB is concerned,
 you'd have to make sure up front that the environment is safe to use,
 which is done by running recovery (DB_RECOVER flag, DB_RUNRECOVERY
 error code) in a single thread or process that has exclusive access
 to the environment.

You can run recovery in a separate process spawned at startup by the 
parent.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
attachment: experiment-scrambled.png

Re: Multiple mod_perl 2.0 installations on one Linux machine

2009-01-19 Thread Torsten Foertsch
On Mon 19 Jan 2009, Adam Prime wrote:
  I thought you could build more than one and load the one you want
  at runtime.  Isn't that what Red Hat does?

 If redhat's shipping more than one mpm, they've patched httpd.

Probably not httpd. At least Suse has not. Instead they configure and 
build a prefork httpd and a worker httpd one by one and then merge the 
result. The apache API does not depend on the chosen MPM. So, almost 
certainly you can build modules (including mod_perl) with one MPM and 
use it with another.

Usually I build mod_perl against a httpd with worker MPM and TEST is 
with both worker and prefork. So far I have never found something that 
went bad only because of the other MPM.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Separate Error log for each virtual host

2009-01-16 Thread Torsten Foertsch
On Fri 16 Jan 2009, fREW Schmidt wrote:
 I would like to configure apache such that the errors for a specific
 virtual host get logged in their own file.  I tried something like
 this:

 VirtualHost *:8080
    ErrorLog C:/location/of/acd/logs/error.log
    Perl
       use lib 'C:/location/of/acd';
       $ENV{MODE} = 'development';
    /Perl
     ScriptAlias / C:/locattion/of/acd
    Location  /
       SetHandler perl-script
       PerlHandler ACD::Dispatch
        Order allow,deny
        Allow from all
    /Location
 /VirtualHost

 But it seems to be ignoring my ErrorLog directive and still puts the
 logs in the regular place. What am I doing wrong?

Are you wondering why all your warn() output is directed to only one log 
file? If yes, then try the logging functions in Apache2::Log instead.

I don't know about windows but on a UNIX-like system the default 
ErrorLog is opened on file descriptor 2 and that happens to be STDERR. 
That's why all the perlish warn()ings go to that file.

You will notice that the methods in Apache2::Log all require a request 
or server object. This is necessary to decide into which error log the 
message should be written. Since the perl warn() lacks that information 
it cannot log to a specific file.

You can override the warn() by either supplying a $SIG{__WARN__} handler 
or by implementing *CORE::GLOBAL::warn=sub {...}. That function can 
then check if Apache2::RequestUtil-request or 
Apache2::ServerUtil-server returns something useful and the use that 
object with Apache2::Log.

If your Apache error messages all go to the same file then your 
configuration is wrong. If you use named virtual hosts you have perhaps 
forgotten the ServerName directive (as Adam pointed out) or your 
requests lacks the Host-header. I think Apache complains in that case 
at startup. Turn on LogLevel debug. For IP/port based vhost you don't 
need either.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: generic enquiry about rendering zipped content

2009-01-16 Thread Torsten Foertsch
On Fri 16 Jan 2009, André Warnier wrote:
 What exact form would a HTTP response need to have, for the browser
 to correctly interpret that the response it is getting is a document
 (for example an OpenOffice document or an email in eml format), but
 which has been zipped for transmission ?

 What I would like to happen is that the browser receives the zipped
 document, but instead of proposing to open it as a zip file or save
 it to disk as a zip file, unzips it and handles it properly as per
 the content of the zipped response.

 I know that this has to do with the Content-Type and
 Content-disposition and Content-encoding (Content-type-encoding ?)
 headers, but do not know exactly what are the caveats or rules or
 things that work with one browser and not the other kind of stuff.

 Does anyone know ?

 If more context is required :
 A server-side application stores on the one hand original documents
 of different kinds, zipped, and on the other hand meta-data about
 these documents in a database and search-engine.
 The user can search the database, and obtain a response html page, on
 which appear icons representing the original documents.  When
 clicking on such an icon, the user should receive the original
 document. It seems a pity, considering that the document is already
 stored zipped at the server side, to unzip it before sending it to
 the browser, so that the browser would know that it is not a
 zip-file, but an OpenOffice document.
 The plan is thus to have, underneath the icons, a link which invokes
 an application on the server (Apache module, mod_perl module,
 cgi-bin,..), which retrieves the zipped original, composes the
 appropriate HTTP headers (wich it can do only based on info stored in
 the db), and sends the document in the appropriate way to the
 browser, in the zipped format. The filename of the zipped document on
 the server gives no clue as to its content. Only the meta-data in the
 db indicates that.

 Thanks in advance for any insights, advice, pointers etc..

You can send the file in DEFLATE format (rfc1951) or in GZIP format 
(1952). The latter happens to be the output of the gzip program. Winzip 
 Co use a different format! I think I do something like you want to.

use APR::Finfo ();
use APR::Const -compile=qw/FINFO_NORM/;
if( $r-finfo-filetype and
$r-headers_in-{'Accept-Encoding'}=~/gzip/ and
-f $r-filename.'.gz' ) {
  $r-filename($r-filename.'.gz');
  $r-content_encoding('gzip');
  $r-finfo(APR::Finfo::stat($r-filename, APR::Const::FINFO_NORM, 
$r-pool));
  $r-headers_out-add(Vary='Accept-Encoding');
}

You have to check if the browser accepts gzip format. Set the 
Content-Encoding header and the Vary header (for proxies). 
mod_negotiation (MultiViews) provides a similar functionality.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: [mp2] a way to map a uri to a physical path

2009-01-14 Thread Torsten Foertsch
On Thu 15 Jan 2009, Foo JH wrote:
 Is there a generic method so that given any uri as a parameter, the
 library can do the math and return the physical path?

If you look for the filename for $r-uri, that means the uri of the 
current request then $r-filename holds that after the map-to-storage 
phase.

If you need a general method to map an arbitrary URI to a filename then 
it is a subrequest:

  my $subr=$r-lookup_uri($uri);
  if( $subr-status == Apache2::Const::OK and
  -f $subr-filename ) {
$filename=$subr-filename;
  }

But keep in mind that it may result in quite unusual filenames if you 
use the mod_proxy handler for example. Also, the file may not exist. 
The status 404 is generated only in the response phase. Further, you 
must perhaps check $subr-path_info for being empty.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Flushing output and preserving headers

2009-01-03 Thread Torsten Foertsch
On Sat 03 Jan 2009, Kate Yoak wrote:
 $r-headers_out-set('Content-Type' = image/gif);

use $r-content_type(...)

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: HTTP Response Headers fixup

2009-01-02 Thread Torsten Foertsch
On Thu 01 Jan 2009, André Warnier wrote:
 It works perfectly, even without having the filter remove itself
 (which I did not know how to do).

http://perl.apache.org/docs/2.0/api/Apache2/Filter.html#C_remove_

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: HTTP Response Headers fixup

2009-01-01 Thread Torsten Foertsch
On Thu 01 Jan 2009, André Warnier wrote:
 Unfortunately the Content-Type header is a different beast. Inside
 Apache it is not only a response header, but a more complex data
 type. You can set a different Content-Type header with mod_headers,
 but since the internal structure remains unchanged it will be
 overwritten again by Apache.

 As a result I see no way to change an existing character set in a
 Content-Type header.

Try to create a request output filter that sets $r-content_type, 
removes itself and returns DECLINED.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Keep-Alive, Apache processes and $r-connection

2008-12-21 Thread Torsten Foertsch
On Sun 21 Dec 2008, André Warnier wrote:
 Am I right, or horribly wrong, to assume that in case of a
 keep-alive client connection, the multiple requests sent over that
 connection will be processed by the same Apache process (child or
 thread) ?

 I am assuming the above, from the fact that there exists a
 $request-connection-notes table.  It seems that it would make
 little sense for such a structure to exist otherwise.

Yes, and there is also a $r-connection-pnotes hash to store perl data 
structures.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: sub-requests, lookup_uri and that kind of stuff

2008-12-21 Thread Torsten Foertsch
On Mon 22 Dec 2008, André Warnier wrote:
 I could do this the hard way by using LWP to just issue a new HTTP
 request to localhost and get the content, before I go on with my
 current request.

 But I figure there must be an easier and more efficient way, no ?

 Looking at the explanations for sub-requests, lookup_uri etc.., I get
 the impression however that calling these, pretty much terminates the
 current request, and replaces it by the one I'm calling.
 Which is not what I want.
 I want to continue processing the current request but using the
 response from my other request.

Look at what mod_include does to get an impression about subrequests. 
You can use subrequests in 3 ways:

1) lookup_uri or similar creates the subreq and runs it up to fixup. 
Then you can use any information the subreq has gathered so far, that 
means authentication, finfo etc.

2) run it to include the output of the subreq into the current document 
more or less unmodified. To do that you create the subreq, install the 
necessary output filters and run() it.

3) run it to process the output in some other way. That can be done for 
example this way:

my $content='';
my $subr=$r-lookup_uri( $uri );
$subr-add_output_filter( sub {
my ($f, $bb) = @_;
while (my $e = $bb-first) {
  $e-read(my $buf);
  $content.=$buf;
  $e-delete;
}
return Apache2::Const::OK;
  });
$subr-run;
my $rc=$subr-status;
my $ct=$subr-content_type;

Now, $content holds the response body, $rc the HTTP status code and $ct 
the subreq's content type.

In all cases a subreq returns control to the calling request. An 
internal_redirect on the other hand almost completely takes over the 
request without return to the calling req.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: content_type in SSI- or directly-called mp2 scripts

2008-12-17 Thread Torsten Foertsch
On Wed 17 Dec 2008, cr...@animalhead.com wrote:
 My mod_perl2 scripts mostly fall into 2 categories:

 1) scripts that are called by URL location, and generate complete  
 content-pages
 2) scripts that are called by SSI include virtual sequences  
 in .html files, and generate part of a page

 In some cases scripts of type 1 directly call scripts of type 2 to  
 generate parts of their pages.
 (Call this case 3).

 My questions are about when to call $r-content_type('text/html')

 Such a call is a good idea in category 1, right?

Each request has a content-type assigned no matter if you set it in your 
script or not. Normally (for static files), that header if figured out 
by one of the mime-modules (mod_mime, mod_mime_magic) in the 
type-checker-phase of the request cycle. But usually it's a good idea 
to set/reset it in your content handler prior to sending any data to 
the client because that handler knows better what it is going to send. 

 Such a call probably should not be made by the directly-called script
   in case 3, right?
 Apache probably can't even tell that a new script has gotten into the
   act, the calling
 and called script are both in the undifferentiated sea of mod-perl  
 code, right?

 In an SSI-invoked script (category 2) is a content_type call a)  
 required, b) good practice,
 or c) a bad idea?

In all cases it is good practice. Virtual include uses subrequests. That 
means when the INCLUDE filter sees a vinclude it stops the output of 
the current request, creates a subrequest for the wanted document, runs 
that document sending the output to the client but ignoring all headers 
save the status. When the subrequest is done the output of the main 
request is resumed. So, in your cases 2 and 3 the Content-Type header 
is ignored. The client sees only the content-type of the main request.

If your included script wants to know the content-type of the main 
request it can use $r-main-content_type (perhaps to adopt the 
character set).

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Problem - Missing input data

2008-12-17 Thread Torsten Foertsch
On Wed 17 Dec 2008, mod_perl User wrote:
 I am facing problem in mod_perl2.0 while opening an handler
 Code as follows,         my $r = Apache2::Request-new(shift,
 POST_MAX = 10 * 1024 * 1024);        my $status = $r-parse(); 
 Getting $status as 'Missing Input Data'

I am not an expert in libapreq but I have seen this when there is no 
request body (GET or empty POST). Use instead

$req=Apache2::Request-new($r);
$r-discard_request_body;  # read in the complete body
$status=$r-method eq 'POST' ? $req-body_status || $req-args_status
 : $req-args_status; 

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net


Re: Question about Apache2::ServerUtil and PerlCleanupHandler

2008-12-05 Thread Torsten Foertsch
On Fri 05 Dec 2008, Kostas Chatzikokolakis wrote:
 I'd like to ask what is the intended behaviour of
  Apache2::ServerUtil-server-push_handlers(PerlCleanupHandler =
 ...) compared to
  Apache2::RequestUtil-request-push_handlers(PerlCleanupHandler =
 ...)

 On my Ubuntu 8.10 (mod_perl 2.0.4, apache 2.2.9) cleanup handlers
 installed on $s seem to be called after *every* request but handlers
 installed on $r are called only *once* after the *current* request.
 On a RedHat ES 5 (mod_perl 2.0.2, apache 2.2.3) cleanup handlers on
 $s look like they are never called.

 I found and old list message suggesting that cleanup handlers on $s
 are called when the server is terminated, but this doesn't seem to be
 the case (and looks strange since we have PerlChildExitHandler for
 that). In the documentation of handlers, there is no mention of where
 each handler must be installed and whether it makes a difference.


 NOTE: on my Ubuntu, a cleanup handler installed on $s is called only
 if there are also other types of handlers on $s. In the Changelog of
 the *threading branch* I found the following message

   Now correctly invokes PerlCleanupHandlers, even if they are the
 only handler type configured for that request [Torsten Foertsch]

 this comes from r594609 but it was not merged for 2.0.4. This maybe
 happens also for $r handlers, but on my setup $r has always at least
 a PerlResponseHandler so I'm not sure.

Apache request configuration is performed in 2 steps. The first occurs 
at startup the second at runtime. At startup one configuration object 
per virtual server is created. At runtime a request inherits from that 
config but other request specific configuration sources (Location 
blocks, .htaccess files etc) are merged.

$s-push_handlers as well as $s-add_config modify the server 
configuration object while $r-... modify the runtime request 
configuration. The server methods are intended to be used only at 
startup time (up to PerlPostConfig, perhaps PerlChildInit works too). 
Later the server configuration must be read-only or you risk segfaults 
at least on a threaded MPM.

The PerlCleanup phase is an artificial thing that is implemented as a 
pool cleanup function on the request pool. But it needs to be 
registered on the request pool to be run. If there is no Perl handler 
in the request cycle the pool cleanup is never installed. The patch you 
mentioned fixes that but it depends on an other interpreter management 
(the heart of the threading branch). Hence, if you need that use the 
threading branch. I use it for quite a time now in production with 
prefork. I know there are issues with worker. So, I don't recommend 
that.

In modperl_callback.c at line 202 you'll find these lines:

   /* XXX: would like to do this in modperl_hook_create_request()
* but modperl_interp_select() is what figures out if
* PerlInterpScope eq handler, in which case we do not register
* a cleanup.  modperl_hook_create_request() is also currently always
* run even if modperl isn't handling any part of the request
*/
   modperl_config_req_cleanup_register(r, rcfg);

This is inside the modperl_callback_run_handlers() function which is the 
central point that runs all PerlXXXHandlers. That's why you need at 
least one PerlXXXHandler to activate the PerlCleanupHandler. In the 
threading branch the modperl_config_req_cleanup_register() call could 
have been moved to the create_request hook as mentioned in the comment.

Torsten

-- 
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mod_perl survey results

2008-11-10 Thread Torsten Foertsch
On Mon 10 Nov 2008, Steven Siebert wrote:
 Let me know how to get involved

How well is your C? There is a segfault waiting to be hunted down. It's 
one of the nicer. It happens each time the test suite runs with worker 
MPM. If interested I can give you further information.

The threading branch at 
http://svn.apache.org/repos/asf/perl/modperl/branches/threading needs a 
few ifdefs to work with perls without threading support. That branch is 
also a good starting point for the segfault above.

Try out the threading branch with the Windows MPM. I don't have Windows 
(and don't care much). So there may be a lot to do.

Further on the line I have a few ideas how to make modperl consume less 
memory when running under a threaded MPM.

I think we really need better threading support to survive. We can of 
course repeat the mantra use prefork ever again. But many apache 
developers tend to use a threaded MPM as default. Some days ago Paul 
Querna even asked how valuable copy-on-write is and if it can be 
dropped in favor of better Windows compatibility. The day will come 
when prefork is not the default MPM even on Unix-like systems.

Of course there is always a need for advocacy, writing papers, 
presentations, case studies, cool solutions etc.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mod_perl survey results

2008-11-10 Thread Torsten Foertsch
On Mon 10 Nov 2008, André Warnier wrote:
 Ok guys, I'm nowhere as good a programmer as many people on this
 list, but a) I do have patience with beginners, b) I'm convinced and
 c) maybe I can do something in terms of documentation, if only to fix
 missing links. And d) I'd love to see my name somewhere as a
 contributor, even at the very end and in small font.
 So, where do I start ?

c) See http://perl.apache.org/contribute/index.html. Lately there have 
been a few complains about missing, incomplete or misleading docs on 
the list. You could start to submit patches. A simple one could be 
this: http://www.gossamer-threads.com/lists/modperl/dev/98380. Find out 
why it was that way in the first place then patch it.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mod_perl survey results

2008-11-10 Thread Torsten Foertsch
On Mon 10 Nov 2008, Steven Siebert wrote:
 More memory but potentially faster, correct?  Since we don't have to
 spawn as many processes to accommodate a load?

Perl is a real memory hog. Byte-compiled code can become quite big. 
Multiply that with the number of perl interpreters running and you'll 
get huge numbers. With the prefork MPM we use the load all modules you 
need at startup mantra. This way the operating system comes to rescue 
with copy-on-write. The byte-compiled code is almost read-only after it 
is compiled. If it is compiled by the perl interpreter in the parent 
apache all that memory becomes shared memory.

With a threaded MPM the situation is different. Here at startup we have 
one perl interpreter that loads all the modules. Then AFTER the child 
is forked it creates as many as configured additional interpreters. 
Each of those is a copy of the master interpreter. But now all the 
memory that holds the byte-compiled code is allocated again for each 
interpreter and almost nothing is shared by copy-on-write. So the 
creation of a new perl interpreter is really expensive.

Although there is one sane usage of modperl with a threaded MPM, I 
believe. If your only modperl usage is to configure the request at 
runtime, do authentication etc you need the interpreter only for a 
small part of the request cycle. So you can configure say 3 
interpreters to handle 250 or so threads. But for that to become usable 
we need a better modperl and perhaps better MPMs (event based).

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Substituting URLs in PerlOutputFilterHandler

2008-11-10 Thread Torsten Foertsch
On Mon 10 Nov 2008, Puneet Lakhina wrote:
 essentially im trying to modify a href=
 tags in the outgoing HTML pages.
 Now I am trying to do this using PerlOutputFilterHandler. I have the
 following questions:
 a) Is this the right filter to use for an application like this?

yes

 b) As per my understanding my hander can be invoked multiple times
 based on the no. of buckets. Is this correct?

yes

 If yes, then how should 
 I handle the situation where a part of the tag like say 'a href'
 comes in one bucket and '=' comes in another.

The basic idea is to carry around the tail of the current buffer, 
the 'a href', in the filter context. The last handler in this chapter

http://perl.apache.org/docs/2.0/user/handlers/filters.html#Stream_oriented_Output_Filters

shows the technique.

The OutputFilter routine in Apache2::ClickPath (on CPAN) is another 
example.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Fwd: MPM-safe mp2 Singleton Pattern?

2008-11-07 Thread Torsten Foertsch
On Fri 07 Nov 2008, Steven Siebert wrote:
 Is there any way to have a MPM-safe (specifically thread-safe)
 singleton pattern?

Modperl manages an interpreter pool if it runs under a threaded MPM. 
That means the first modperl-related action in the request cycle pulls 
an interpreter from the pool. Some time later the interpreter is the 
put back to the pool. The point in time when that happens is defined by 
the PerlInterpScope directive. It can happen immediately after the 
current phase in the request cycle or when the request is over or when 
the client connection is dropped. (And you can have a separate 
interpreter for a subrequest.) Perl variables allocated in one 
interpreter are accessible only from that interpreter unless they are 
marked as shared. Shared variables are implemented by the 
thread::shared module. This module creates another shared perl 
interpreter that does the actual memory management. A shared variable 
is then allocated inside that special interpreter and another one is 
allocated inside the current interpreter. Then that variable is tied 
to the variable in the shared interpreter in a similar way to what the 
tie() command does.

So for what you want you need to make sure (if I understood your 
problem) that the same instance is used throughout the request cycle. 
Plus you want that it is destroyed when the request is over.

The simplest way is to put the object as a pnote:

sub getInstance {
  my $r=shift;

  return $r-pnotes-{Logger} if exists $r-pnotes-{Logger};
  return $r-pnotes-{Logger}=Logger-new;
}

No global $this!

When the request pool is destroyed all pnotes are destroyed as well.

In theory that also binds the current interpreter to the pool. That 
means it makes sure that the interpreter stays the same at least as 
long as the request pool exists no matter what PerlInterpScope says. 
But there were bugs with that in the past. So perhaps you have to 
upgrade your modperl.

And finally an advice, don't use a threaded MPM with modperl in 
production! If you want to help with the code it would be appreciated. 
A good starting point is the threading branch at 
http://svn.apache.org/repos/asf/perl/modperl/branches/threading

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Mod Perl 2.0 HTTP Handlers

2008-11-02 Thread Torsten Foertsch
On Sun 02 Nov 2008, Torsten Foertsch wrote:
 On Sun 02 Nov 2008, Puneet Lakhina wrote:
   Input headers are found in $r-headers_in and are set even before
   PerlPostReadRequest. So, have a close look at your code. If that
   doesn't help try to create a test case as simple as you can and
   post it to the list.
 
  Not as per this:
  http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_heade
 rs _in_

 Then the documentation is wrong.

To show you that that is not an modperl-thing but implemented that way 
in apache, let's have a look at the ultimate docs. In 
httpd-2.x.y/server/protocol.c you'll find the ap_read_request function. 
It reads in a request, finds the virtual host that handles the request 
and calls PostReadRequest handlers. It is a bit lengthy. So I have 
removed the unnecessary for the problem stuff and put in a few 
comments:

request_rec *ap_read_request(conn_rec *conn)
{
...
r-headers_in  = apr_table_make(r-pool, 25);

Here $r-headers_in is created as an empty table.

/* Get the request... */
if (!read_request_line(r, tmp_bb)) {

This reads the first request line, something like GET / HTTP/1.1

if (!r-assbackwards) {
ap_get_mime_headers_core(r, tmp_bb);

And this line reads in the headers and populates $r-headers_in.

if (apr_table_get(r-headers_in, Transfer-Encoding)
 apr_table_get(r-headers_in, Content-Length)) {

You see, even the function itself uses $r-headers_in.

ap_update_vhost_from_headers(r);

Another example of $r-headers_in usage. Here the correct 
NamedVirtualHost is found. This function needs the Host request header.

if ((access_status = ap_run_post_read_request(r))) {

And here a PerlPostReadRequestHandler is called.

...
}


Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Mod Perl 2.0 HTTP Handlers

2008-11-02 Thread Torsten Foertsch
On Sun 02 Nov 2008, Puneet Lakhina wrote:
 Initially I thought PerlTransHandler would be the right thing to use.

It is.

 But as it turns out, the headers arent populated until that phase.

Input headers are found in $r-headers_in and are set even before 
PerlPostReadRequest. So, have a close look at your code. If that 
doesn't help try to create a test case as simple as you can and post it 
to the list.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Mod Perl 2.0 HTTP Handlers

2008-11-02 Thread Torsten Foertsch
On Sun 02 Nov 2008, Puneet Lakhina wrote:
 One more question, is it possible for me to ensure that my module/or
 essenially mod_perl's processing of the URI translation happens
 before mod_rewrite or any other similar modules, and essentially
 mod_rewrite's rules work on the URI modified by me.

That order is defined by the 4th parameter to ap_hook_translate_name(). 

mod_rewrite calls it as:

ap_hook_translate_name(hook_uri2file, NULL, NULL, APR_HOOK_FIRST);

and mod_perl as:

ap_hook_trans(modperl_trans_handler, NULL, NULL, APR_HOOK_REALLY_FIRST);

APR_HOOK_FIRST and APR_HOOK_REALLY_FIRST are integer numbers. Hence, you 
can write APR_HOOK_REALLY_FIRST-42 or so.

The actual definitions can be found in 
srclib/apr-util/include/apr_hooks.h:

/** run this hook first, before ANYTHING */
#define APR_HOOK_REALLY_FIRST   (-10)
/** run this hook first */
#define APR_HOOK_FIRST  0
/** run this hook somewhere */
#define APR_HOOK_MIDDLE 10
/** run this hook after every other hook which is defined*/
#define APR_HOOK_LAST   20
/** run this hook last, after EVERYTHING */
#define APR_HOOK_REALLY_LAST30

So, a PerlTransHandler is always called before the mod_rewrite 
translation handler since APR_HOOK_REALLY_FIRST is less than 
APR_HOOK_FIRST. The only way to change that is to patch and recompile 
one of the modules.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: $r-filename, can I do this here ?

2008-10-17 Thread Torsten Foertsch
On Fri 17 Oct 2008, André Warnier wrote:
 In a PerlFixupHandler, I want to use $r-filename to reset the target
 of a PUT request, so as to trick the following Apache PUT content
 handler into writing the PUT-ted file somewhere else than what the
 original URL said.

Yes you are allowed to do that. One thing you may have to consider is 
the $r-finfo object (sort of stat() result). It is created in the core 
maptostorage handler. So, if $r-filename is changed afterwards it is 
out of sync. Don't know if your response handler uses it, probably not.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: $r-filename, can I do this here ?

2008-10-17 Thread Torsten Foertsch
On Fri 17 Oct 2008, André Warnier wrote:
 Any way I can kind of force Apache to update it's
 information after I call $r-filename, or does it already do that
 anyway ?

See the example in
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_filename_

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-15 Thread Torsten Foertsch
On Tue 14 Oct 2008, Torsten Foertsch wrote:
 On Tue 14 Oct 2008, André Warnier wrote:
  When I try this, I get an Apache error with the following logfile
  message : [Tue Oct 14 16:10:40 2008] [error] [client
  84.158.163.207] $r-add_config() has failed: SetHandler not allowed
  here at /usr/local/lib/apache2/perllib/AUTH/StarLogCookie.pm line
  414.\n

 That is an apache error. SetHandler needs the FileInfo override flag,
 see http://httpd.apache.org/docs/2.2/mod/core.html#sethandler. So,
 the correct command would be:

   $r-add_config(['SetHandler ...'], Apache2::Const::OR_FILEINFO)

 or simpler

   $r-add_config(['SetHandler ...'], ~0)

 (since you know what directive you are adding).

Maybe others are interested too, here are 2 private messages:

On Wed 15 Oct 2008, André Warnier wrote:
 Ok, I did, and it seems to work too :

 So I have 2 sequences that work :
 a)
   $r-add_config(['SetHandler modperl'], ~0);
   $r-set_handlers(PerlAuthzHandler = []); # disable authorization
   $r-set_handlers(PerlResponseHandler = \_send_login_form);
   #$r-set_handlers(PerlFixupHandler = sub {
 $_[0]-handler('modperl') } );

 b)
   #$r-add_config(['SetHandler modperl'], ~0);
   $r-set_handlers(PerlAuthzHandler = []); # disable authorization
   $r-set_handlers(PerlResponseHandler = \_send_login_form);
   $r-set_handlers(PerlFixupHandler = sub {
 $_[0]-handler('modperl') } );

 Now, can you explain ?
 I don't even understand what ~0 means..

On Wed 15 Oct 2008, Torsten Foertsch wrote:
 On Wed 15 Oct 2008, André Warnier wrote:
  1) you mentioned that it was due to a Apache bug.

 Did I really say bug? I meant an Apache error message. You'll see the
 same message if you try something like that:

 Directory /
 AllowOverride AuthConfig
 /Directory

 and then have an .htaccess with a SetHandler directive in it.
 SetHandler needs AllowOverride FileInfo. But only AuthConfig is
 set.

 The 2nd parameter to add_config is a AllowOverride bit field. It
 limits what kind of directives are allowed to be added. Think of it
 as if you have read the directives from an untrusted source (like
 .htaccess).

  2) I do not have a clue why the above would work around that bug.

 Apache wants here not only to be told to add the SetHandler but also
 to be ensured Yes, that is what I want. Just do it!.

 ~0 means all bits turned on.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: SetHandlers question, Phase II

2008-10-15 Thread Torsten Foertsch
On Wed 15 Oct 2008, André Warnier wrote:
  I think you're wanting:
 
       $r-set_handlers(PerlFixupHandler = sub
  {$_[0]-handler('modperl')});

 Yes.  That works.

Better to return something sane from the handler:

sub {$_[0]-handler('modperl');0}  # 0==Apache2::Const::OK

Also consider push_handlers instead of set_handlers. In case other 
modules already have set a fixup handler.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Apache2::Request in PerlInitHandler and PerlAuthenHandler

2008-10-14 Thread Torsten Foertsch
On Tue 14 Oct 2008, Shibi NS wrote:
 And the ARULink::MetalinkAuth::handler is

 sub handler
 {
 my ($req) = @_;

 my $status;
 my $username;
 my $userid;
 my $email;

 #
 # Create a Session object.
 #
 my $req_params = $req-args;
 my $cgi= CGI-new($req_params);
 my $session= ARU::Session::get_cgi_session($cgi);
 $req-subprocess_env;

 
 }

 When my handler reaches line '(my $cgi= new CGI($params);)' the
 application is spinning ,seems like $req-args is returning null and
 application line number 354 of CGI which is $req-subprocess_env;

 Error from log file

 Warning:
 Deep recursion on subroutine CGI::new at
 /m/isd/pm/ARULink/MetalinkAuth.pm line 114.

Don't know about CGI in this context but is there any chance to switch 
to Apache2::Request (libapreq2)?

If you really see an empty $r-args at that stage while you are certain 
to have passed something then it is an error in mod_perl. Try to create 
a test case as short and simple as you can and file a bugreport.

Try something like

  warn params: .$req-args;

The warning will appear in the error_log.

Can you please be more detailed about where it spins in CGI.pm? My 
version 3.29 looks like:

   350if ($MOD_PERL) {
   351  if ($MOD_PERL == 1) {
   352$self-r(Apache-request) unless $self-r;
   353my $r = $self-r;
   354$r-register_cleanup(\CGI::_reset_globals);
   355  }
   356  else {
   357# XXX: once we have the new API
   358# will do a real PerlOptions -SetupEnv check
   359$self-r(Apache2::RequestUtil-request) unless $self-r;
   360my $r = $self-r;
   361$r-subprocess_env unless exists $ENV{REQUEST_METHOD};
   362$r-pool-cleanup_register(\CGI::_reset_globals);
   363  }
   364  undef $NPH;
   365}

Line 354 is somewhere in the mp1 code path. The mp2 code path looks 
correct for me. Apache2::RequestUtil-request is set up in 
postreadrequest and again in headerparser if +GlobalRequest. 
cleanup_register() is also allowed here.

Ah, does your code check for a subrequest? Something like return ... if 
$r-main or return ... unless $r-is_initial_req? If not you may see 
it spinning in the subprocess_env line if your $r-path_info is not 
empty. The reason is a subrequest issued during $r-subprocess in void 
context to compute the standard CGI variable $ENV{PATH_TRANSLATED}. 
Apache does that by $r-lookup_uri($r-path_info). Assuming you don't 
have a download, ARULink or WebApp directory in your DocumentRoot the 
whole URI will be in $r-path_info as well. So, the subrequest will hit 
the same location container an thus the authen handler. Just a guess.

On Tue 14 Oct 2008, André Warnier wrote:
 Now, below :
   SetHandler              perl-script
 is used when your purpose is to run a traditional cgi-bin script
 under mod_perl, not for embedded modules like your
   PerlResponseHandler     ARULink::handler
 would indicate.
 I suggest you try replacing this first by
 SetHandler modperl

Sorry André but that is not entirely true. perl-script vs. modperl 
simply means you want the more sophisticated response handler. It 
affects only the response phase. Since the authen handler comes prior 
to that it is irrelevant here. More sophisticated means you want %ENV 
tied to $r-subprocess_env, tied *STDIN, *STDOUT, etc. The main reason 
for me to avoid the perl-script handler is that it uses PerlOptions 
+SetupEnv as default. That calls ap_add_cgi_vars() and that computes 
$ENV{PATH_TRANSLATED} the IMHO most useless CGI variable. To do that it 
issues a subrequest.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-14 Thread Torsten Foertsch
On Tue 14 Oct 2008, André Warnier wrote:
 I doubly appreciate not only because my immediate problem is solved,
 but also because I learned a lot in the process.

Try the $r-add_config again with the right override flag (OR_FILEINFO) 
and you'll see it will also work.

 It seems to me that this whole thread could be collected and
 re-arranged into a Tutorial on mod_perl phases, authentication,
 interactions with Apache etc..  but honestly at the moment I don't
 know where to begin.

Find a place where you think it would fit and send in a patch, see 
http://perl.apache.org/contribute/svn_howto.html#Working_with_SVN on 
how to get the source.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-14 Thread Torsten Foertsch
On Tue 14 Oct 2008, André Warnier wrote:
 When I try this, I get an Apache error with the following logfile
 message : [Tue Oct 14 16:10:40 2008] [error] [client 84.158.163.207]
 $r-add_config() has failed: SetHandler not allowed here at
 /usr/local/lib/apache2/perllib/AUTH/StarLogCookie.pm line 414.\n

That is an apache error. SetHandler needs the FileInfo override flag, 
see http://httpd.apache.org/docs/2.2/mod/core.html#sethandler. So, the 
correct command would be:

  $r-add_config(['SetHandler ...'], Apache2::Const::OR_FILEINFO)

or simpler

  $r-add_config(['SetHandler ...'], ~0)

(since you know what directive you are adding).

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-14 Thread Torsten Foertsch
On Tue 14 Oct 2008, André Warnier wrote:
 At this moment, I cannot see clearly how the ErrorDocument solution
 would allow me to send back a login page created dynamically, as I
 need to do.  I will look it up, but as a definitive solution for the
 time being I would prefer the $r-internal_redirect method, where I
 can see more clearly how to do this.

Location /secured
PerlAuthenHandler sub { \
  return Apache2::Const::FORBIDDEN unless ...;
}
ErrorDocument 403 /login
/Location

Location /login
SetHandler modperl
# you still have to supply a login_form function that expects a
# $r object.
PerlResponseHandler sub { \
  my $r=shift; \
  $r-content_type('text/html'); \
  $r-print(login_form($r-prev));
  return Apache2::Const::OK;
}
/Location

Your A-handler returns 403. Instead of sending the standard FORBIDDEN 
page to the browser apache catches the error because of the 
ErrorDocument directive. /login looks like an URI. Hence apache will 
perform an internal redirect to it. /login is configured in the 
normal modperl-way.

The browser will see an HTTP status of 403 (it will also be logged as 
403). But the message sent along will be the output of login_form. And 
that is what the user will see. login_form has access to the original 
request. So, it can pass the original URI in a hidden field.

See also http://httpd.apache.org/docs/2.2/mod/core.html#errordocument

Instead of 403 you can also use 401 if you want to use 
http-authentication. That is the user will see a browser generated 
password box. But I doubt that is what you want.

 But I still have some (hopefully) last questions, if you would be so
 kind :

 As I understand this, the internal_redirect() basically stops the
 current request, and replaces it in-place by a totally new request,
 except that in that new request, $r-prev will be set to the
 (original) request that did the redirect, right ?

Yes. Best if you return OK from the current handler right after the 
$r-internal_redirect line.

 (So in the new request, I can still access the pnotes set by the
 original request, via $r-prev-pnotes()).

Yes.

 For this new request, the cycle restarts right at the beginning, and
 runs through all the steps just as if this was a main request. Right
 ?

AAA are possibly skipped as I mentioned before.

 Are there any other significant differences between this new request
 and the previous one that I should be very aware of (in a
 mod_perl/AAA context) ?

You'll find some, ;-)

 One thing I do not really understand, is what happens to the original
 request, when it issues a call to $r-internal_redirect().
 Does the original request still run to completion, or does it abort
 right there ?

I think you'll see the original request again in the logging phase.

 Does Apache still return something to the browser for the original
 request, or is that completely replaced by whatever the new
 (redirected) request produces ?

No, not unless you have sent something prior to the internal_redirect.

 After the call to $r-internal_redirect(), should the original
 request still do something ? (like return Apache2::Const::?) ?

OK, see 
http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_internal_redirect_

 P.S.
 I have downloaded the Apache source, and looked at the code within
 httpd-2.x.y/server/request.c, but it is still a bit obscure to me,
 except in a very general sense.  I kind of approximately follow the
 steps, but do not always understand aspects like why it re-does
 directory walks at several stages, nor can I see at all where
 mod_perl plugs in to that code.

great! Many treasures are hidden there.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-14 Thread Torsten Foertsch
On Tue 14 Oct 2008, André Warnier wrote:
 reminder of my config :
  LocationMatch /servlet.xyz$
      SetHandler jakarta-servlet
...
  /Location

 And, in summary, what I was trying to do is :
 if the PerlAuthenHandler finds that the request is not authenticated,
 then it tries to change the response handler for this request, from
 the original jakarta-servlet handler, to my own response handler,
 which in fact returns a login page.
 (I need something active to return the login page, because I need
 to insert some data into the login page prior to returning it).

 And for that I used this code in the PerlAuthenHandler :

 # set our own response handler
 $r-handler('modperl');
 $r-set_handlers(PerlResponseHandler = \_send_login_form);
 return OK;

The problem is the $r-handler statement. The program flow is this:

- ...
- uri translation
- map to storage
- Location container is applied
  the SetHandler directive is applied to the requests configuration
  structure. That does not mean $r-handler is set. It is simply noted
  there is a SetHandler directive active for the request.
- aaa
- ...
- fixup
  the SetHandler value is copied to $r-handler. See
  httpd-2.x.y/server/core.c:core_override_type()

if (conf-handler  strcmp(conf-handler, none))
r-handler = conf-handler;

  That means $r-handler is set only if there was a SetHandler directive
  and if it was not SetHandler none.

So, that leads us to 4 possible solutions:

1) remove the SetHandler directive from the Location container and set 
$r-handler either to jakarta-servelet or to modperl in your aaa 
handler. It won't be touched if other modules don't kick in. mod_dir 
comes to mind but it reads (fixup handler):

/* In case mod_mime wasn't present, and no handler was assigned. */
if (!r-handler) {
r-handler = DIR_MAGIC_TYPE;
}

So, that's not a problem. But there may be other modules that don't 
check that.

2) replace $r-handler('modperl') in the aaa phase by 
$r-add_config(['SetHandler modperl']). This way you override the 
handler set in the configuration structure. In the fixup phase it is 
then automagically copied to $r-handler.

3) leave the $r-handler('modperl') and add a 
$r-add_config(['SetHandler none']);

4) set $r-handler in a fixup handler.

$r-add_config works very similar to

Location /
your directives
/Location

The only difference is the time when it is applied to the config struct. 
That config is reset after the translation phase. So it is useless to 
try $r-add_config before. Location containers from the httpd.conf are 
applied after MapToStorage. So anything you do in your own MapToStorage 
handler can be overridden in Location containers even if your handler 
returns OK to skip the core MapToStorage handler.

But anything applied after that, that means from the header-parser phase 
onward overrides the httpd.conf settings.

 One of the possibilities envisioned previously was :
  Or, a thought that just occurred to me, is the solution for me
  (stopping jakarta-servlet from running and running my
  PerlresponseHandler instead), as easy as setting the no-jk
  variable (if I can do that within my PerlAuthenHandler, and how) ?
 
  I was tempted to suggest that. But I don't know nothing about
  jakarta. If you want to try use $r-subprocess_env-{'no-jk'}=1;

 I tried this, because it was the smallest possible change to my
 module. It works, in the sense that it sets the no-jk variable,
 which consequently has the effect of making the jakarta-servlet
 handler above not process this link.
 But it is not a solution for me, since what happens is that the
 jakarta-servlet handler is in fact still executed by Apache as the
 response handler, but it probably just returns DECLINED.

That's what I thought it would.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-13 Thread Torsten Foertsch
On Sun 12 Oct 2008, André Warnier wrote:
 Location /some/url

    SetHandler jakarta-servlet
    SetEnvIf REQUEST_URI \.(htm|web|css|gif|jpg|js|html?)$ no-jk

    PerlXXXHandler My::Module-some_method

    ...

 /Location

 (jakarta-servlet above means mod_jk -- Tomcat)
 (and PerlXXXHandler being any kind of Perl HTTP Handler running soon
 enough)

 The Question :
 Is it possible, in the PerlXXXHandler, on a request-by-request base,
 to disable the jakarta-servlet handler, and install the following
 instead

    SetHandler modperl
    PerlResponseHandler My::Module-some_other_method

 ?

 I know that I can do something like the above for regular static
 pages, and I use this already :
    $r-handler('modperl');
    $r-set_handlers(PerlAuthzHandler = []); # stop authorization
 from running
    $r-set_handlers(PerlResponseHandler = \_send_login_form);


 However, when I try to do the same in a Location like the above, it
 seems that the jakarta-servlet handler runs anyway, and my
 PerlResponseHandler is never called.

Does that piece of code run in a /Perl(PostReadRequest|Trans|
MapToStorage)Handler/ ?

Please, have a look again at the ap_process_request_internal() function 
in httpd-2.x.y/server/request.c. This function implements almost the 
complete request cycle (save PostReadRequest, Response and Log).

Just after ap_run_translate_name(), that is the PerlTransHandler, you'll 
see this piece:

/* Reset to the server default config prior to running 
map_to_storage
 */
r-per_dir_config = r-server-lookup_defaults;

if ((access_status = ap_run_map_to_storage(r))) {
/* This request wasn't in storage (e.g. TRACE) */
return access_status;
}

/* Rerun the location walk, which overrides any map_to_storage 
config.
 */
if ((access_status = ap_location_walk(r))) {
return access_status;
}

/* Only on the main request! */
if (r-main == NULL) {
if ((access_status = ap_run_header_parser(r))) {
return access_status;
}
}
...

The line r-per_dir_config = r-server-lookup_defaults; resets all 
request specific configurations applied so far. After that line the 
request is configured as if no Directory/Location or other container 
were present in your httpd.conf. Next comes MapToStorage. Here 
Directory, DirectoryMatch, Files and FilesMatch containers are applied 
to the request. Then, and this is what I think hits you, comes an 
ap_location_walk. Here Location containers are applied. So, your 
SetHandler inside the Location overrides any $r-handler seen before.

After the ap_location_walk comes the PerlHeaderParserHandler. But it is 
skipped for subrequests. A further examination will show you that the 
next phase that is run by all requests is the PerlTypeHandler just 
before Fixup. So, move your $r-handler('modperl'); to one of those 
and it will work. I prefer Fixup but that is based only on the fact 
that it is documented as do-what-you-want phase. There are directives 
that change the handler in the type-checker phase. In fact the 
AddHandler directive works that way. Mod_mime looks at the file 
extension and adjusts the handler, e.g AddHandler cgi-script .pl. So 
using Fixup your module is the last to kick in.

To carry state around use pnotes, notes or subprocess_env.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: sethandlers question

2008-10-13 Thread Torsten Foertsch
On Mon 13 Oct 2008, André Warnier wrote:
 As explained the other thread (requests and subrequests), I thought
 it was more elegant and mod_perl-ish, instead of doing a re-direct to
 a login page if the user needed authentifying, to having the login
 page returned by a content handler.

The apache-way to do this has a name: ErrorDocument or in mod_perl 
$r-custom_response. Configure an ErrorDocument for 403 and return 
HTTP_FORBIDDEN in your A...Handler. That has the benefit that the 403 
status is logged and that the browser (think about search engines) sees 
it. But the custom response page must be larger than 512 bytes or 
you'll encounter problems with IE. If you don't care about that you can 
use $r-internal_redirect. That is a bit less work to do for your 
server.

  Please, have a look again at the ap_process_request_internal()
  function in httpd-2.x.y/server/request.c.

 I would first have to know where this thing is.  I have never so far
 looked at the Apache source code, so I need some pointers there.
 Not that if I look, I would necessarily understand much of it, but I
 can try.
 Now, why would I, since you provide the nice explanation below ?

Out of curiosity! Just download the apache source untar it and open in 
in your favorite editor. C is not that much different from perl and the 
request.c file is really easy to read. You don't have to modify it, 
just try to understand what is going on!

 So, you mean that for every and each request, Apache re-configures
 itself ?  If that is so, it is quite amazing the speed at which it
 can serve a page..

Just keep in mind for the following that apache is originally designed 
to have a static configuration. So at start it splits the configuration 
into blocks, one holds the basic config that is outside all containers 
and others for each Location/Directory/etc. From those blocks it 
generates pre-parsed configuration vectors. At runtime each request 
starts with the basic config fetched from r-server-lookup_defaults 
then it looks for other vectors matching the request and merges them.

But there is another configuration source, .htaccess. Those are read in, 
compiled and merged in the same function (ap_directory_walk() (hard to 
understand)) that applies Directory containers (called from 
ap_run_map_to_storage()).

With mod_perl comes yet another configuration source, $r-add_config. 
This is implemented very similar to .htaccess only the directives are 
not read from a file but from memory and they are compiled and merged 
at the time $r-add_config is called.

 Well, I am not sure :
 The handler set in the configuration file for that Location, is
 originally jakarta-servlet (as per the snippet below).
 It is I, in my PerlAuthenHandler, who is trying to reset this to
 modperl, and in mod_perl, to my send_login_page() method.
 Before I do that, there is no $r-handler nor PerlResponseHandler
 set.

So, why not issue a $r-internal_redirect. I don't exactly know when the 
SetHandler directive sets $r-handler. Maybe it is done in the type 
checker phase. So perhaps you have to move your code to Fixup or use 
$r-add_config(['SetHandler modperl']).

 I don't think I can do that, unless I want the PerlTypeHandler or
 PerlFixupHandler to become an authentication handler.  That would
 probably for one upset Adam, for two be kind of funky, no ?

Why not?

if( $override_handler ) {
  $r-push_handlers( PerlFixupHandler=__PACKAGE__.'::fixup' );
  $r-pnotes-{override_handler}='modperl';
}
...
sub fixup {
  $_[0]-handler($_[0]-pnotes-{override_handler};
  return Apache2::Const::OK;
}

 Now, in summary :
 This is a very specialised authentication module, meant to be used in
 very specific circumstances and not for general usage.  I control the
 environment, so I can pretty much do what I want as long as it does
 not crash the system or present some big security hole or the like.

 In my case, that Location containing the
 sethandler jakarta-servlet
 is pretty much unique: it is not a sub- or super-location of anything
 else, and it fulfills only one very narrow purpose.
 To my knowledge, there will be no other module playing a role there,
 other than the jakarta-servlet initial handler, plus whatever I
 decide to put in there as mod_perl modules and methods.
 This for the entire duration of one request.

 Now, assuming I have no other stuff in there than the following lines
 LocationMatch /servlet.xyz$
     SetHandler jakarta-servlet
     SetEnvIf REQUEST_URI \.(htm|web|css|gif|jpg|js|html?)$ no-jk

     AuthType MyModule
     AuthName MyXyzApp
     PerlSetVar MyModule_var1 value
     PerlAccessHandler My::Module-some_access_method
     PerlAuthenHandler My::Module-some_auth_method
     PerlAuthzHandler My::Module-some_authz_method
     require valid-user

 /Location

 then, if I understand correctly what you write above, since I have no
 PerlTransHandler, nor Fixup, etc..  I should be able to do the same
 in the PerlAuthenHandler, is it no so ?
 Or 

Re: requests and sub-requests

2008-10-12 Thread Torsten Foertsch
On Sun 12 Oct 2008, André Warnier wrote:
 In an attempt at being clever, I put the following code in the
 handler :

      unless ($r-is_initial_req) {
          if (defined $r-prev) {
              # we are in a subrequest.  Just copy user from main
 request. $r-user( $r-prev-user );
          }
          # Also disable authorization phase
          $r-set_handlers(PerlAuthzHandler = undef);
          return OK;
      }

You have to distinguish between subrequests and internal redirects. The 
former result from $r-lookup_uri, $r-lookup_file or similar (there 
are a few more such functions in the C API) and internal redirects that 
result from $r-internal_redirect (internal_fast_redirect() is not as 
the name suggests an internal redirect but simply overrides the current 
request). Subrequests are used for example by mod_rewrite, mod_include, 
mod_negotiation to look for some characteristics of a document and 
perhaps pull it in (run() it). Internal redirects are used in mod_cgi 
when the CGI output indicates a status 200 (HTTP_OK) but also contains 
a Location header. But the main usage of internal redirects is the 
ErrorDocument.

Now, is_initial_req() checks if the current $r is the result of a 
subrequest or the result of a internal redirect and returns false if 
so. prev() returns the parent request if the current $r is the result 
of an internal redirect and main() returns the main request if the 
current $r is a subrequest. So, your code checks only for internal 
redirects (ErrorDocument).

Now, have a look at httpd-2.x.y/server/request.c around line 170. You'll 
see this piece of code:

/* Skip authn/authz if the parent or prior request passed the
 * authn/authz,
 * and that configuration didn't change (this requires
 * optimized _walk()
 * functions in map_to_storage that use the same merge results given
 * identical input.)  If the config changes, we must re-auth.
 */
if (r-main  (r-main-per_dir_config == r-per_dir_config)) {
r-user = r-main-user;
r-ap_auth_type = r-main-ap_auth_type;
}
else if (r-prev  (r-prev-per_dir_config == r-per_dir_config)) 
{
r-user = r-prev-user;
r-ap_auth_type = r-prev-ap_auth_type;
}
else {
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
if ((access_status = ap_run_access_checker(r)) != 0) {
return decl_die(access_status, check access, r);
...

You see, you are not the first who had had the idea of reusing an 
established identity. If your subreq or internal redirect hits the same 
Location or Directory container the AAA phases are completely skipped.
Maybe this is enough optimization if you shift a few directives around 
in your httpd.conf.

If not, the code above shows you how to do it. But you must ask yourself 
if it really is valid to reuse the identity. I believe, you can safely 
inherit the identity from $r-main or $r-prev but you must not skip 
the other 2 A's. If you can't it would mean you have one realm of 
identities for the main request and another for the subreq. That, I'd 
say, is a configuration error.

 The idea being that if we are in a sub-request, there is no point in
 authenticating/authorizing it again, since the main request should
 already do that, right ?  Optimisation..

 Now the above works very nicely, except in the case where, before
 this handler gets called, there is an intervention by mod_rewrite. It
 seems as if mod_rewrite makes the above fail, even when the rewrite
 condition does not apply and the URL is considered as a
 pass-through.

 I suspect that it is because mod_rewrite, no matter what, invoques
 the original (or modified) URL as a sub-request of the original
 request. This would cause the above to fail, because in such a case,
 the above conditional code would be invoked, but there is no
 $r-prev-user to be copied.

mod_rewrite doesn't make subrequests if not asked to. I know only of 2 
ways to have mod_rewrite perform a subreq: %{LA-U:variable} 
and %{LA-F:variable} in a RewriteCond.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: requests and sub-requests

2008-10-12 Thread Torsten Foertsch
On Sun 12 Oct 2008, André Warnier wrote:
 I have a little question related to the above, but not very urgent :
 why the check on the configuration change ? what can change between a
 request and a sub-request (or internal redirect) ?

Suppose this:

Location /mainreq
Require group foo
/Location

Location /subreq
Require group bar
/Location

If during the processing of /mainreq a subreq is issued to /subreq the 
other Require group must be respected. Of course there also can be 
another AuthUserFile or so, so that the identity could not be 
established and the subreq results in a 401. I'd consider that as a 
configuration error.

The configuration change mentioned above means the different Location 
containers. They are represented as $r-per_dir_config.

 I don't think so, because this is a really specific authentication
 method, for a special case.
 And I don't think that Apache will skip the mod_perl AAA phases, will
 it ?

Yes, mod_perl handlers are called inside these ap_run_... functions. 
ap_run_access_checker() is the first of the 3 A's. A PerlAccessHandler 
is called from this function.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: questions on Apache2::Connection

2008-10-11 Thread Torsten Foertsch
On Sat 11 Oct 2008, André Warnier wrote:
 Do I understand this correctly that if in a Perl Handler i get
 my $c = $r-connection();
 then $c is the object that represents the persistent TCP/IP
 connection between the browser and the server, in case there is
 keep-alive going on ?

 Now lets say that I create an authentication method based on the
 Request (as they tend to be usually).
 On the first request, the authentication happens, and I set a
 $c-notes('credentials') value. I also set a browser cookie.

Yes, connection notes and connection pnotes are persistent across 
keep-alive requests.

 On subsequent requests, I could check this $c-notes('credentials')
 first, in case a previous request over the same connection already
 resulted in authentication, could I not ?

 In the worst case, the connection is new and I would not have these
 notes (meaning I then need to get the cookie, and in its absence redo
 an authentication); but in the vast majority of cases (depending on
 keep-alive), I could save myself some overhead by considering the
 connection as authenticated instead of the request, no ?

 Or are there some pitfalls here of which I am ignorant ?
 Or is the potential gain not worth the cost of getting the
 $r-connection ?

I see 2 points to consider:

1) A reverse proxy in front of the web server can maintain a persistent 
connection to the backend but server different clients and thus spoil 
your caching.

2) The combination of prefork-MPM, mod_perl and keep-alive is perilous 
on the Internet because one apache process is locked over the whole 
keep-alive time. A malicious client sends one request and let the kept 
alive connection time out by the server. A single client can eat up all 
your servers in a very short time. Of course a similar attack is 
possible based on the server's TimeOut setting but they are a bit 
trickier. You deploy that combination directly on the Internet but you 
have to have a close look at the TimeOut and KeepAliveTimeout settings. 
Make them as short as you can.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Free to wrong pool error in Apache logs under high load

2008-10-10 Thread Torsten Foertsch
On Fri 10 Oct 2008, Scott Tomilson wrote:
 I am running a build of mod_perl I got via perl.apache.org, yes (or I
 think probably linked to uwinnipeg?).  No other modules than the
 standard ones, plus the standard ActivePerl download from
 ActiveState.  We actually tried the same solution on Solaris and it
 worked fine.  It does seem specific to Windows itself - or more
 likely ActivePerl on Windows...

The windows MPM is multithreaded, the prefork MPM that you have probably 
used on Solaris is not. That makes a difference.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Internal redirect inside an input filter

2008-10-09 Thread Torsten Foertsch
On Thu 09 Oct 2008, Dan DeSmet wrote:
 I'm attempting to write an input filter that performs an internal
 redirect based on the contents of the cookies sent in the request
 headers.

Why an input filter? What you want is better done in a PerlTransHandler 
or a PerlFixupHandler.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: [MP2]: strange behavior with Apache2::SubRequest::run

2008-09-19 Thread Torsten Foertsch
On Fri 19 Sep 2008, titetluc titetluc wrote:
  Does your mod_perl one return Apache2::Const::REDIRECT at the end?

 No, the module returns Apache2::Const::MOVED_TEMPORARILY, setting the
 Location header by using $r-err_headers_out

$ perl -MApache2::Const=REDIRECT,HTTP_MOVED_TEMPORARILY -le 'print 
REDIRECT; print HTTP_MOVED_TEMPORARILY'
302
302

Guess what that means.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: How to extract the protocol part of URL from an apache request

2008-09-17 Thread Torsten Foertsch
On Wed 17 Sep 2008, grsvarma019 wrote:
 But , i couldn't find how to extract the protocol(http or https )

There are Apache2::ModSSL and Apache::SSLLookup on CPAN in case you need 
that information in a request phase prior to the ResponseHandler. 
Mod_ssl can be configured to export SSL information as environment 
variables. Those can be looked up in a ResponseHandler via 
$r-subprocess_env.

Further, if you are unable to install an XS module (precompiled 
mod_perl+apache on windows without C compiler for instance) and you 
need SSL information prior to the response phase you can issue a 
subrequest to get it. Not the fastest way but it works. I have 
described that technique in a previous mail to the list this or last 
year.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: How to extract the protocol part of URL from an apache request

2008-09-17 Thread Torsten Foertsch
On Wed 17 Sep 2008, John ORourke wrote:
 I had the same problem but the machine serving the request had a
 reverse proxy in front of it.  I used the following to inject a
 header on the proxy:

         SetEnv SCHEME http
         RewriteCond %{HTTPS} on
         RewriteRule ^(.*) $1 [E=SCHEME:https]

Yes, I think that should work as well without the reverse proxy. 
Mod_rewrite talks directly to mod_ssl.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: How to pass the post data to a script

2008-09-17 Thread Torsten Foertsch
On Wed 17 Sep 2008, grsvarma019 wrote:
 If the requested script of an application needs POST data, that data
 is not being sent to the requested script ,but instead it is being
 captured by apache request object of the mod_perl.

 How can i pass this data to the requested script?

First, see if libapreq2 can help!

If it doesn't you can try to implement a request input filter that 
caches the data on disk while mod_perl does $r-read or 
$r-discard_request_body and a second one that reinserts that input for 
the script. Not sure if that works.

The first part looks similar to that:

use Apache2::Const -compile=qw/M_POST OK/;
use APR::Const -compile=qw/SUCCESS/;
use Apache2::Filter ();
use APR::Bucket ();
use APR::Brigade ();

if( $r-method_number==Apache2::Const::M_POST ) {
  my @content;
  my $cl=0;
  my $rc=$r-add_input_filter( sub {
my ($f, $bb, $mode, $block, $readbytes) = @_;

my $rv = $f-next-get_brigade($bb, $mode, $block, $readbytes);
return $rv unless $rv == APR::Const::SUCCESS;

for (my $b = $bb-first; $b; $b = $bb-next($b)) {
  $b-read(my $bdata);
  $cl+=length $bdata;
  push @content, $bdata;
}

return Apache2::Const::OK;
  } );
  $r-discard_request_body;
  $r-pnotes-[EMAIL PROTECTED];
  $r-pnotes-{rbody_length}=$cl;
}

Well, it saves the request as pnotes but it shows the principle. The 
second part is a bit trickier if not impossible. You'll have to modify 
the input filter chain again, insert a filter that creates buckets from 
the saved data. But I don't know if that works once EOF has been seen 
on input.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: using MOD_PERL with script causes looping

2008-09-11 Thread Torsten Foertsch
On Wed 10 Sep 2008, csross wrote:
 On a solaris 8 server with Apache 2.6 and perl 5.8.8, we have an
 html/javascript file that uses HTTP Post to a perl script.  The perl
 script sends data back via HTTP get to a redirected HTML file. The
 HTML file strips off data from the command line of the URL (suff
 after the ?) and then posts more data to the perl script until all
 of the data it needs is retreived. This works fine in perl without
 mod-perl enabled, but loops in modperl, as if the initial connection
 for the first request is still open and the same data is being
 endlessly sent back.  This happens on later versions of Solaris as
 well.

 We did find that after what seems like many interations of the
 looping, the data finally get processed and the subsequent screen
 appears, but that is after a minute at least.  When not using
 mod_perl, this doesn't happen.  The developer wanted to put in a
 wait type command to see if that worked, but it did not make a
 difference.

 Has anyone seen this type of behavior?

I think the reason is that the perl script holds some status. The 
difference between mod_perl and CGI is that the former uses the same 
interpreter again and again while the latter starts the interpreter 
anew each time. So, if the script doesn't clean up things properly it 
may look different for the second request.

You probably also use KeepAlive requests. That would explain the fact 
that it worked after many requests. Either the server or the browser 
has dropped the connection. The browser then establishes a new one and 
probably hits another perl interpreter. That one is still in pristine 
state. Hence it worked.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mod_perl 2 and IPC::Open3

2008-09-05 Thread Torsten Foertsch
On Thu 04 Sep 2008, Tina Müller wrote:
      $pid = open3($wtr, $rdr, $err,
          '/usr/bin/source-highlight', '-s', 'perl', '-css',
 '--no-doc');
  print $wtr $content; 
      close $wtr;
      warn __PACKAGE__.':'.__LINE__.: before read loop\n;
      while ($rdr) {
          # this is not executed
          warn __PACKAGE__.':'.__LINE__.: line $_\n;
          $highlighted .= $_;
      }

Don't know if it relates to the problem but this code is quite fragile. 
It depends upon whether $content completely fits into the operating 
systems pipe buffer. In your program the print $wtr or the close $wtr 
statements may infinitely block if $content is too large.

To illustrate that try this:

perl -e 'pipe my ($r, $w) or die pipe: $!\n; print $w xx64000; 
warn printed\n; close $w;'

Here a pipe is created and written to but never read from. This example 
succeeds on my linux box. If 64000 is raised to 69000 the print $w 
succeeds and I see the output of warn(). But the process never ends. It 
is blocked in the close() operation. If the buffer length is raised a 
bit further to 7 I don't even see the warning. The process is 
blocked in the print() operation. The pipe buffer size depends upon the 
operating system. So your numbers may vary.

I'd recommend to rewrite that piece based on either perl's select(), 
IO::Select or some kind of event library like Lib::Event, EV, Event or 
even POE. In all cases you have to use non-blocking IO for reading and 
writing combined with sysread/syswrite.

Further, I'd suggest a bit of error handling. All those operations 
open3, print, close may fail. Only open3 reports the failure via an 
exception.

Also, you may want to watch out for SIGPIPE.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: question on downloading CGI

2008-09-05 Thread Torsten Foertsch
On Fri 05 Sep 2008, [EMAIL PROTECTED] wrote:
 I want to generate a data file which should be downloaded by clients.
 Rather than generate this file and put it in a web dir and tell
 clients to download it, is there any way to generate the content
 dynamicly and put it to cients? I mean I don't want to generate the
 temporary file.

Plenty.

For example in your httpd.conf

Location /download
SetHandler modperl
PerlResponseHandler sub {   \
  use Apache2::RequestRec ();\
  use Apache2::RequestIO (); \
  use Apache2::Connection ();\
  $_[0]-content_type('application/octet-stream');   \
  until($_[0]-connection-aborted) {\
$_[0]-print(rand);  \
  }  \
  return 0;  \
}
/Location

Now restart your server and then

curl -v http://server/download

And you'll get never ending randomness.

You can also write a little shell script and use it via mod_cgi:

 the shell script
#!/bin/bash
echo Content-Type: application/octet-stream
echo
cat /dev/urandom
 end of shell script

Now fetch the Apache docs and configure your server to execute the 
script as CGI program.

Remember it is not necessarily faster to send dynamic content this way. 
Sometimes it is faster to write a temporary file sometime before the 
response phase and let the default handler send it. If you decide to 
send the content on the fly try to figure out the content length and 
set the Content-Length header. This can also improve your performance.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: Prototype mismatch: sub main::strftime

2008-08-26 Thread Torsten Foertsch
On Tue 26 Aug 2008, Darragh Gammell wrote:
 Subroutine main::strftime redefined at
 /usr/share/perl/5.8/Exporter.pm line 66.
  at /home/secure/public_html/tagtag/send.cgi line 10
 Prototype mismatch: sub main::strftime: none vs ($\@;$) at
 /usr/share/perl/5.8/Exporter.pm line 66.
  at /home/secure/public_html/tagtag/send.cgi line 10

I think use Date::Format (at line 10 in send.cgi) exports its own 
version of strftime. That way it redefines the one exported by POSIX. 
That leads to the redefined warning. Further, one of the functions 
has a prototype while the other one hasn't. Hence comes the prototype 
mismatch.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mp2, IPC::Run3 Environment Variables giving variable not set error

2008-08-16 Thread Torsten Foertsch
On Sat 16 Aug 2008, Berg, Eric wrote:
  Now, the environment is a process global resource. So, if
  those values are changed all threads are affected. This is surely
  no what you want.

 When you say that the environment is a global process, global to
 what?  Each forked process has its own environment, doesn't it?  It
 seems to me from the brief piece in the User Guide about this and
 what you've said, that threaded environments are the real problem
 here.  In the case of threaded environments, the environment is
 shared among all threads, whereas forked processes can and do have
 distinct environments per process.  Is this correct?  That means (as
 suggested in the relevant source comments) that a solution for the
 forked MPM would be much easier than for those that are threaded.
  Right?

Correct. The words a process global resource above mean a resource 
that is global to the process.

Btw, another way to manipulate the environment is using the modperl 
handler instead of perl-script. This way %ENV remains tied to the 
environment and changes will show up after a perl fork.

See also 
http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#C_Libraries_Don_t_See_C__ENV__Entries_Set_by_Perl_Code

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mp2, IPC::Run3 Environment Variables giving variable not set error

2008-08-15 Thread Torsten Foertsch
On Fri 15 Aug 2008, Berg, Eric wrote:
 This issue of the environment variables' not being passed to forked
 processes is turning into a fairly substantial problem for me.   We
 have a number of places in our code -- both the modules that are
 tightly controlled and fairly easy to manage, as well as a bunch of
 scripts and CGI's that use them -- that use system or backticks
 (sometimes via IPC::Run3) to get info from external tools.

 Does anybody know anything about this issue or about the code
 involved?  How difficult would it be to address this?  I took a look
 at the code in modperl_env.c as suggested in the docs, but I'm a Perl
 guy, not a C guy.  

 This is a deal killer for us.  

Let's have a look at the reason for this behavior first. It's always 
better to know what you are doing. Apache 2.x can use various MPMs. 
Some of them use threads instead of processes to achieve parallelism. 
Now, the environment is a process global resource. So, if those values 
are changed all threads are affected. This is surely no what you want.

Therefore there is a request specific data structure called 
subprocess_env where environment variables for CGI scripts are kept. If 
you use the Apache interface to spawn subprocesses 
(Apache2::SubProcess) you'll notice that variables set in 
subprocess_env appear as environment variables of the spawned process. 
Under mod_perl %ENV is tied to $r-subprocess_env.

If you are using the prefork MPM (as you probably do) you can still 
manipulate the environment without affecting other requests. But you 
have to use the C-level functions. There is a module called Env::C on 
CPAN that provides a perl interface to them.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: mod_perl 2.0 fails on make

2008-08-15 Thread Torsten Foertsch
On Fri 15 Aug 2008, Fred Moyer wrote:
  When I run 'make'. It goes pretty fair but it ends with this.
 
  modperl_exports.c:1169: error: `modperl_thx_interp_get' undeclared
  here (not in a function)
  modperl_exports.c:1173: error: `modperl_thx_interp_set' undeclared
  here (not in a function)
  make[1]: *** [modperl_exports.o] Error 1
  make[1]: Leaving directory
  `/home/charlier/modperl-2.0/src/modules/perl' make: ***
  [modperl_lib] Error 2
 
  Is there any known fix to work around this?

 Try with the 2.0.4 stable version of mod_perl.  Also I would suggest
 building mod_perl as a shared object (dynamically, not statically),
 so would say remove the MP_USE_STATIC=1.  I've seen people get it to
 work but almost everyone I know builds mod_perl as a loadable module
 instead of into the httpd binary.

Agreed, the static build is a bit neglected. But without MP_USE_STATIC 
also the current SVN version should work.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


  1   2   3   4   >