Re: Where is the mod_perl development repo?
Hello. I am catching this at the end, but the general subject interests me, and I'd like to know more. Should I start a new thread ? and what best to name it ? My situation : I am not a hot-shot programmer nor perl expert, but over time I have written quite a few mod_perl-based pieces of code, roughly in 2 categories : 1) one category which interacts quite heavily with the Apache request processing phases and with the Request object, such as authentication, various kinds of proxying, wraps around DAV to make it do what I want, output filters etc. 2) another category of things which could have been done using CGI and Apache::Registry (processing submits etc.), but since I was already doing the first kind above, I've done these by creating add-on mod_perl modules instead. (Which do sometimes rely on something that has been done by the first category, like $r->pnotes). But if really "It is now the recommended approach to PHP and other scripting endpoints" (including, I suppose, perl), it looks like I would slowly have to change my strategy. If I understand the general idea correctly, it consists of no longer running complicated and memory-hungry things directly in Apache through mod_perl, but to use Apache as a front-end reverse proxy, and proxy such calls to one or more back-end processes having their own persistent perl (or other) interpreter. Is that correct ? Intuitively, I would imagine that the approach below fits my second category more than the first, right ? So, for the second type, where could I best start reading ? (Contrarily to the original poster, I am perfectly happy with Perl 5, and not looking at Perl 6 yet. I am also not really a fan of very abstract "frameworks", because of their general "all or nothing" approach. Template::Toolkit is about my limit). On 09.03.2017 04:30, William A Rowe Jr wrote: Explore the idea of wrapping your app as an fcgid endpoint. Httpd has two options (mod_fcgid managing the pool, and mod_proxy_fcgi with your own choice of independent pool management.) This offers the best of both... Larger number of httpd endpoints and less contention between fcgi processes. It is now the recommended approach to PHP and other scripting endpoints. On Feb 19, 2017 06:50, "Tom Browder" wrote: On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz wrote: "Tom" == Tom Browder writes: ... Randall, I do know that, and I love Perl 6! I also feel comfortable writing CGI programs, so how can I use both most efficiently with my apache web server.? Best regards, -Tom P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016. Thanks for all your contributions to the Perl community!
Re: Cache refresh each 50 queries?
Hi. On 04.10.2016 10:17, SUZUKI Arthur wrote: [...] On 03.10.2016 16:57, SUZUKI Arthur wrote: Hello List, I'm sending this message to know if there are some hints/tips to help with the problem we're facing. The problem is that for a same query repeated over time, reply time can be as short as 5ms and as long as 1s. Since there is neither correlation with CPU load or RAM usage, nor any networking constraints, we think it is due to the cache refresh mechanism. The problem occurs at random times, with a probability of around 1/50 queries (empirical data). Is there any configuration option which could help? Our current httpd.conf contains the following: PerlModule ModPerl::Registry PerlOptions +Parent PerlSwitches -I/home/koha/src SetHandler perl-script # more faster, link with worker PerlResponseHandler ModPerl::Registry # less faster, link with prefork #PerlResponseHandler ModPerl::PerlRun Options +ExecCGI PerlOptions +ParseHeaders Thanks a lot in advance for your replies. Best regards, You still do not provide enough information about your server configuration (the part not mod_perl specific) to really make a narrow guess, but let me try anyway : One thing that might explain a seemingly-long processing time for a request approximately once in 50 calls, is if there was something special and resource-intensive which happens once per approximately 50 calls, right ? One thing which /might/ explain this, /perhaps/ and depending on your configuration, is if approximately once in 50 calls, Apache had to fork a new child process, to handle the call. This new child process would then start with a brand-new, fresh Perl interpreter, which might need to recompile some modules before it even starts handling the request. Look for example here : http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ and your configuration line above : PerlOptions +Parent In that configuration, the cgi-bin script which you are running (and all its dependencies), is not compiled by the embedded perl until it has been run at least once. So the first execution will take more time than the following ones. Now if the rest of your configuration is so that every 50 requests or so, Apache starts a new child with a new perl interpreter, that may explain the symptoms that you are observing. When Apache handles a request (if it is a "prefork" MPM), it will look for a child Apache which is free, to pass the request for execution. If the server is lightly loaded, it may be that the child to which it passes the next request is always the same, because it is always done with the previous request, and free, when the next request comes in. But if this child process somehow has a limit to how many requests it may process before it dies, and this limit was around 50, then somewhere around the 50th request, another child would get the next request, and for this child it would be the first one (or the first one with /this/ cgi-bin script). There are roughly similar phenomenons that might happen in other kinds of Apache MPM's, which is why it is important to know which one you are using, and with which setup parameters. And yes, there are ways to improve this. But again, we would need to know more about your configuration in order to make suggestions.
Re: WELCOME to modperl@perl.apache.org
Hi and welcome indeed. Maybe one thing first : when posting to the list, do not just hit "reply" on a message that you received previously. Create a *new* message, with a subject corresponding to what you are asking. Then later, when someone responds, you can "reply" and keep the subject identical. One reason is that these messages usually go into list archives, where people can later search for messages based on the subject, to see if their problem was not already solved previously. If it was, and they find it, that is a big gain of time, for everyone. See here : https://perl.apache.org/maillist/modperl.html#Searchable_Archives But with a subject like "Welcome to modperl", there is not a big chance that anyone would find this message, or the future responses to it. The other reason is : people subscribed to this list, receive these messages in their email Inbox. And they may decide to look at the message, and maybe help, based on the subject of the message. Again in that case, a message with a subject "Welcome to modperl" means that some people who might potentially help you, will not even look at your message. So I suggest to re-post your question, as a new message, with an appropriate subject. And when you re-post your message, please add some more details about your Apache httpd configuration, which may help to help you. For example : what kind of MPM are you using ? (prefork, worker, ?) what are the settings for KeepAlive MaxKeepAliveRequests KeepAliveTimeout and the following kind of thing, specific to the MPM used : StartServers MaxClients MinSpareThreads MaxSpareThreads ThreadsPerChild MaxRequestsPerChild etc.. and go have a look at the archives, maybe your question is already answered there. For example here : http://mail-archives.apache.org/mod_mbox/perl-modperl/201610.mbox/browser See how a good subject helps ? On 03.10.2016 16:57, SUZUKI Arthur wrote: Hello List, I'm sending this message to know if there are some hints/tips to help with the problem we're facing. The problem is that for a same query repeated over time, reply time can be as short as 5ms and as long as 1s. Since there is neither correlation with CPU load or RAM usage, nor with networking constraints, we think it is due to the cache refresh mechanism. The problem occurs at random times, with a probability of around 1/50 queries (empirical data). Is there any configuration option which could help? Our current httpd.conf contains the following: PerlModule ModPerl::Registry PerlOptions +Parent PerlSwitches -I/home/koha/src SetHandler perl-script # more faster, link with worker PerlResponseHandler ModPerl::Registry # less faster, link with prefork #PerlResponseHandler ModPerl::PerlRun Options +ExecCGI PerlOptions +ParseHeaders Thanks a lot in advance for your replies. Best regards,
Re: Bad rap
On 13.06.2016 14:09, John Dunlap wrote: We use Amazon Cloudfront for serving all of our static content. The only thing we load from Apache is an index.html file to bootstrap into Ember.js. In our experience, Cloudfront delivers static content to the browser 5-6 times faster than our servers can. So, practically all of our requests serve dynamic content. Also, I didn't mean that Apache is slow or that it isn't a great web server per say but rather that, due to its single thread per request model, does anyone do better ? multiple threads per request ? some new kind of parallel quantum computing ? Sorry, I guess you meant something else, but in this case maybe it helps to be precise ? (or, I am willng to learn if there is a model which I don't know yet) it cannot accept as many concurrent connections as Nginx can. Now, as I have not had time to experiment with Perl+Nginx, I cannot speak to whether or not there are offsetting performance penalties incurred by FCGI. I can tell you that, at some point, I'm going to experiment with it. On Mon, Jun 13, 2016 at 7:16 AM, James Smith wrote: All our experiences at work with nginx/psgi & nginx/fastcgi are poor - it is very good if any of your queries takes any length of time and/or the fastcgi/psgi requests are requested a lot relative to the static content served by nginx then there are quite significant error/performance issues In our case the only static files are mainly images.. The rest of the content is dynamic - whether it is server cached pages or real dynamic content... We have a load balancing proxy in-front of our apaches so we can fork content elsewhere that is to be served fast! We don't because Apache itself is fast enough! Admittedly we have taken a lot of care to reduce the overall number of requests to a minimum (page, 1 CSS, 1 JS + a handful of images per page) The hacks we would have to do in PSGI/FastCGI to get these features would probably be negated by the move away from Apache Apache is fast enough if you use it properly!! On 6/13/2016 11:58 AM, John Dunlap wrote: Speaking as someone would like to migrate to Nginx, at some point, the big advantage of Nginx really has nothing to do with mod_perl. It has to do with Apache. The way Apache processes requests is fundamentally slower than Nginx and, consequently, Nginx scales better. On Jun 13, 2016 6:54 AM, "James Smith" wrote: Just posted: mod_perl is a much better framework that PSGI, FastCGI IF you make use of the integration of perl into all the stages of apache (you can hook into about 15 different stages in the Apache life cycle. We make of extensive use of the input, output filters, AAA-layers, clean up, logging, server startup, etc processes then it is one of the best web frameworks you can use. We have sites where content is produced by either being static, mod_perl, php, and java (or proxied back from some ancient CGI software) all processed by the same mod_perl code in the output filter to look the same! or different if was using a different site! If all you are interested in is wrapping CGI scripts in a cached interpreter for performance then yes you can move to one of these other frameworks - but then you have already spent lots of time and effort implementing the features that are virtually free with apache/mod_perl! On 6/11/2016 7:11 PM, Vincent Veyron wrote: Hi all, See this post on reddit : https://www.reddit.com/r/linuxadmin/comments/4n5seo/apache_22_mod_perl_to_nginx/ Please help set the record straight. Ancient technology WTF? -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: random token re-used in subsequent requests [SOLVED]
On 31.05.2016 18:40, Vincent Veyron wrote: On Fri, 27 May 2016 09:29:36 +0200 André Warnier wrote: The above strongly hints at some flaw in the srand() of perl, when called by a 32-bit perl, on a 64-bit OS/machine. Maybe it is worth passing this info along to the perl (language) developers, at www.perl.org ? Sorry for the delay getting back to you : since I wiped and re-installed the machine, I created a virtual machine with a 32bit image, so that took a little time. And, guess what? I can't reproduce the problem in the VM. Also, it only appeared in mod_perl, not perl. The bug may have to do with a cpan upgrade I did on the machine, that generated quite a bit of errors, and messed my system somehow. Thanks for the feedback. But now you have a 32-bit machine + OS, and a 32-bit perl, right ? The problem before happened on a 64-bit machine, with a 64-bit OS, but a 32-bit perl, no ?
Re: random token re-used in subsequent requests [SOLVED]
On 26.05.2016 16:01, Vincent Veyron wrote: On Mon, 16 May 2016 16:38:18 +0200 Vincent Veyron wrote: Out of five different servers, the code works fine on four machines, and a different token is generated every time the page is loaded or re-loaded. On one server however, a previous token is being re-used Hi, The faulty server was installed with 32-bit binaries on a 64-bit processor. I did a clean re-install using 64-bit binaries (debian stable AMD64), and the problem went away. ab -n 2 -c 5 "" now generates 2 unique keys. Speed also increased from 40 to 70 pages/second Thanks for reporting this. The above strongly hints at some flaw in the srand() of perl, when called by a 32-bit perl, on a 64-bit OS/machine. In the course of this discussion, I remember citing some article found on the web, which was talking about something along those lines (such as the fact that only the lower or upper 32 bits were being used or so). Maybe it is worth passing this info along to the perl (language) developers, at www.perl.org ?
Re: random token re-used in subsequent requests
On 18.05.2016 01:23, Vincent Veyron wrote:
On Tue, 17 May 2016 20:41:28 +0200
demerphq wrote:
If you fork before you call (s)rand then each child process will have
their own copy of the flag, which will be false, and thus will cause
srand() to be called in the subprocess properly.
So now I'm lost : I understand this as meaning that one should _not_ call srand
in mod_perl, since each child process is forked by Apache?
In any case, I tried to use srand per André's suggestion and your other post:
my $seed = time ^ $$ ;
srand($seed);
No, this will re-seed it every time, which is also not the point.
The explicit call to srand(), in any given child, should happen only once.
Maybe you can try a BEGIN block. If I remember correctly, under mod_perl (if you run under
"registry" to keep the compiled cgi-bin in memory), a BEGIN block should be run only once,
when the script is first compiled (by this child).
Now, "demerphg" says that this is all not valid, according to the perl source - which he
consulted and I did not - so it is only my own best guess.
But it is not very expensive to try.
my $token = pack "LC*", time, map int rand 256, 1..32 ;
my $session_id = encode_base64($token);
It does not solve the problem : the same key is regenerated several times, I
suppose because time is in seconds, and the machine serves 40 requests/second,
so the seed gets reused?
I tried using /dev/random, but this dies after two requests
my $seed;
open(RAND, "/dev/random") or die "no /dev/random?\n";
read (RAND, $seed, 4);
close(RAND);
srand(unpack("L", $seed));
Many posts on the web suggest using modules such as Math::Random. If I have to
install additional modules, I'd prefer to use the Debian packaging system, for
maintenance reasons. Is libcrypt-random-seed-perl a possibility?
Still don't understand why the problem does not show up in the other machines,
no matter what I throw at them.
Re: random token re-used in subsequent requests
On 17.05.2016 20:26, demerphq wrote: On 17 May 2016 at 20:23, demerphq wrote: On 16 May 2016 at 20:03, Bruce Johnson wrote: On May 16, 2016, at 10:15 AM, André Warnier (tomcat) wrote: join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ; looks at first sight to me like quite inefficient and probably likely to generate the same string regularly, even if it does not look that way. (The only variable there is rand(), and it can only return values between 0 and 62). The function is meant to map a random element from the 62-element-long array (0..9,"a".."z","A".."Z”) (hence a rand() call to generate a number from 0 and 62), 32 times, and join them into a string. Although I think that should really be rand(9+26*2) to properly generate array indices for the entire array and no more. With a number between 0 and 62 (63 numbers) and a 62-element array, you’ll be retrieving nulls from the array 1/62 calls, but all that means is that the string is one char shorter for each time '62’ comes up... So long as rand is properly seeded, you should not get repeats, at least not frequently enough to ever notice, I’d think. This is textbook Perl, as in I’m pretty sure it’s out of one of Larry Wall’s books; I use it to generate random strings for cookies. If it’s properly seeded in the original code, it should either work or not work on all five servers. Not working on one out of the five makes me think maybe there’s some sort of weird caching issue. Or for some reason one of the servers goes through a code path where it calls srand/rand prefork. An unfortunate side effect of the rules of srand in perl is that if you fork without calling rand each child process will have their own seed. if you rand before fork then all the children will have their own seed. Sorry, that should read "if you rand before fork then all the children will SHARE THE SAME SEED". I personally consider this a bug in Perl, but I doubt it will get fixed. I think that the children will share the same seed in any case. (That sounds kind of biblical..). The point is, all children have initially a copy of the same pristine perl interpreter, and the initial grand-father seed (to the initial srand()) is in there somewhere. Only if each child starts by an srand($my-own-unique-seed), will they subsequently get a different sequence of rand() responses.
Re: random token re-used in subsequent requests
On 17.05.2016 14:11, Vincent Veyron wrote:
On Tue, 17 May 2016 10:16:43 +0200
André Warnier wrote:
I don't see above any signifiant difference in configuration between the
servers, apart
from the fact that the "faulty" server runs a 64-bit version of perl.
Sorry : slightly digressive rant about the fact that every time I compare my
configs, I find some subtle differences. Should be getting into config
management tools, but that takes time too.
Now I also found this :
http://rabexc.org/posts/randomizing-should-be-easy-right-oh
I am not sure that I really understand this all the way down, but would this
not be a
suspect in a case where the behaviour seems different between one 64-bit
machine, and a
bunch of 32-bit ones ?
Nope; same results on both types when running the script
This being said, it still looks to me as if the current code is flawed on *all*
machines,
and *will* repeat keys quite often. It just depends again on the exact sequence
of
requests hitting a specific Apache, and the other parameters I mentioned before.
I still believe that the fact that it does not *seem* to happen, is just due to
the
inherent randomness of these other factors on the production machines.
Well, I already posted a test with ab and 12 000 requests, so not sure about
the 'quite often' part?
This is on the faulty one :
@arsene:~$ perl -le '%h=();for (1..10_000_000) {my $session_id = join "", map
+(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32;$h{$session_id}=1};$v=keys %h; print $v'
1000
Yes, but this is *one* process. Each independent process, if you consider the keys, will
get a succession of different answers from rand(), and thus generate different keys.
But if n different processes were all starting with the same initial seed, they would all
generate the *same* sequence of rand() responses, and the same sequence of keys.
And that is what I am saying : each of your Apache pre-fork children is a separate
process, but they all always start with the same random seed.
So they will all, ultimately, generate the same sequence of keys (but not necessarily at
the same time).
Let's say that there are initially 5 Apache children, and that Apache never starts more
than 5.
Now you start bombarding the server with hundreds of requests, all of them triggering the
key-generation mechanism.
And let's say that it takes your module 1 s. to respond to a request (just to make things
simpler below).
T0 :
Request #1 comes in.
The main Apache looks for a free child, and finds child #1.
It passes request #1 to child #1.
This child will be busy until T0 + 1s.
T0 + 0.1s :
Request #2 comes in.
The main Apache looks for a free child.
Child #1 is still busy, so it finds child #2.
It passes request #2 to child #2.
This child will be busy until T0 + 2s.
and so on..
(child 5 is now busy until T0 + 5 s.)
Request #6, at T0 + 0.6s) :
Now all 5 children are busy, and Apache has to wait with the request, until
one child becomes free (*).
In this very simplified case, it will be child #1, at T0 + 1s.
At T0 + 1s, child #1 becomes free again. So child #1 now gets request #6, which for him is
only the *second* request that it processes.
So it generates *its* key #2 (which globally is the generated key #6).
In this very simplified example, the first 5 keys generated globally by Apache will be
identical, because each child starts with the same seed, and they are all called neatly in
a regular sequence.
And then the next 5 keys will be identical, because for each child it is now the second
request.
And so on.
But in a real situation :
- not all requests come in so neatly at regular intervals
(so for example child #1 may become free, before child #5 is even called once).
- not all requests take the same time to serve (other things happen on the
server)
- not all requests generate a key (so if child #4 is called but does not call rand(), it
does not count; or if it calls rand() only 5 times instead of 32, that screws up the whole
sequence, and it will now start generating keys that are different from all the others)
- the number of children will vary over time. New ones will be created as
needed,
some older ones will die and be replaced by a brand-new one. Each time that happens, the
new child will start with key #1 again, because it jus got a brand-new perl. While at the
same time, there may still be an older child alive, for which the next key is already
number 5000 in its own sequence.
- etc..
And this "disorder" will tend to be larger, the more loaded is that server.
So over any given period of time, each child will tend to be at a different stage in his
rand() calls. And the risk of having the same key being returned to 2 clients at about the
same time, is relatively low.
But if the keys are stored somewhere in a persistent way, you are increasing the risk
greatly,
Re: random token re-used in subsequent requests
On 17.05.2016 08:28, Vincent Veyron wrote: On Mon, 16 May 2016 22:45:14 + "Bruce Johnson" wrote: I don’t think it would be likely for Vincent to ever see this once, let alone have it rise to the issue of a problem if it were strictly about non-randomness of the rand() function. Indeed : I also use the function to generate cookies; the strings are stored in a database table with a primary key on the token ; running 'ab -c 4 -n 4000 "http://my/url/here";' 3 times yields 12 000 unique keys on a functional server. The machine where the error showed up can't get two different strings in a row. It's a backup server, so I'm the only one using it for test purposes, which is why I did not notice the error before; it may have been present for a long time. Below is what is installed on each machine, the first one (arsene) being the faulty one; it is a rather old Dell desktop, the others are dedicated servers in datacenters, such as kimsufi.com, online.net. Everything is on bare metal, and incidentally not as uniform as I thought :-( reload-perl is installed but disabled in apache2.conf perl -v on the faulty machine (arsene) : This is perl 5, version 20, subversion 2 (v5.20.2) built for i586-linux-gnu-thread-multi-64int perl -v on the good ones : This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi arsene (cpuinfo : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz) ii apache2 2.4.10-10+deb8u4 i386 Apache HTTP Server ii apache2-bin 2.4.10-10+deb8u4 i386 Apache HTTP Server (modules and other binary files) ii apache2-data 2.4.10-10+deb8u4 all Apache HTTP Server (common files) ii apache2-mpm-prefork 2.4.10-10+deb8u4 i386 transitional prefork MPM package for apache2 ii apache2-utils2.4.10-10+deb8u4 i386 Apache HTTP Server (utility programs for web servers) ii apache2.2-common 2.4.10-10+deb8u4 i386 Transitional package for apache2 ii libapache2-mod-apreq22.13-4+b1 i386 generic Apache request library - Apache module ii libapache2-mod-perl2 2.0.9~1624218-2+deb8u1 i386 Integration of perl with the Apache2 web server ii libapache2-reload-perl 0.12-3 all module for reloading Perl modules when changed on disk ii libapache2-request-perl 2.13-4+b1 i386 generic Apache request library - Perl modules kimsufi (cpuinfo : Intel(R) Atom(TM) CPU N2800 @ 1.86GHz) ii apache2 2.4.10-10+deb8u4 amd64Apache HTTP Server ii apache2-bin 2.4.10-10+deb8u4 amd64Apache HTTP Server (modules and other binary files) ii apache2-data 2.4.10-10+deb8u4 all Apache HTTP Server (common files) ii apache2-mpm-prefork 2.4.10-10+deb8u4 amd64 transitional prefork MPM package for apache2 ii apache2-utils2.4.10-10+deb8u4 amd64Apache HTTP Server (utility programs for web servers) ii apache2.2-common 2.4.10-10+deb8u4 amd64 Transitional package for apache2 ii libapache2-mod-apreq22.13-4+b1 amd64 generic Apache request library - Apache module ii libapache2-mod-perl2 2.0.9~1624218-2+deb8u1 amd64 Integration of perl with the Apache2 web server ii libapache2-reload-perl 0.12-3 all module for reloading Perl modules when changed on disk ii libapache2-request-perl 2.13-4+b1 amd64 generic Apache request library - Perl modules online (cpuinfo : VIA Nano processor U2250 (1.6GHz Capable)) ii apache2 2.4.10-10+deb8u4 amd64Apache HTTP Server ii apache2-bin 2.4.10-10+deb8u4 amd64Apache HTTP Server (modules and other binary files) ii apache2-data 2.4.10-10+deb8u4 all Apache HTTP Server (common files) ii apache2-mpm-prefork 2.4.10-10+deb8u4 amd64transitional prefork MPM package for apache2 ii apache2-utils 2.4.10-10+deb8u4 amd64Apache HTTP Server (utility programs for web servers) ii libapache2-mod-apreq2 2.13-4+b1 amd64generic Apache request library - Apache module ii libapache2-mod-perl2 2.0.9~1624218-2+deb8u1 amd64Integration of perl with the Apache2 web server ii libapache2-request-perl 2.13-4+b1 amd64generic Apache request library - Perl modules ovh (cpuinfo : Intel(R) Celeron(R) CPU 220 @ 1.20GHz) ii apache2 2.4.10-10+deb8u4 amd64Apache HTTP Server ii apache2-bin 2.4.10-10+deb8u4 am
Re: random token re-used in subsequent requests
On 16.05.2016 20:03, Bruce Johnson wrote: On May 16, 2016, at 10:15 AM, André Warnier (tomcat) wrote: join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ; looks at first sight to me like quite inefficient and probably likely to generate the same string regularly, even if it does not look that way. (The only variable there is rand(), and it can only return values between 0 and 62). The function is meant to map a random element from the 62-element-long array (0..9,"a".."z","A".."Z”) (hence a rand() call to generate a number from 0 and 62), 32 times, and join them into a string. Although I think that should really be rand(9+26*2) to properly generate array indices for the entire array and no more. With a number between 0 and 62 (63 numbers) and a 62-element array, you’ll be retrieving nulls from the array 1/62 calls, but all that means is that the string is one char shorter for each time '62’ comes up... So long as rand is properly seeded, you should not get repeats, at least not frequently enough to ever notice, I’d think. This is textbook Perl, as in I’m pretty sure it’s out of one of Larry Wall’s books; I use it to generate random strings for cookies. Maybe the textbook example was meant to show the power of the syntax, but not necessarily the efficiency of it. I interpret this as doing the following (if we ignore any optimisation which the perl compiler may make by itself) : quote perldoc map EXPR,LIST Evaluates the BLOCK or EXPR for each element of LIST (locally setting $_ to each element) and returns the list value composed of the results of each such evaluation. In scalar context, returns the total number of elements so generated. Evaluates BLOCK or EXPR in list context, so each element of LIST may produce zero, one, or more elements in the returned value. unquote LIST in this case is 1..32 = 32 elements. EXPR is (0..9,"a".."z","A".."Z") which is another list (say LIST-2), of 62 elements. Thus, we are 32 times evaluating (building) a list LIST-2 of 62 elements. (Always the same one, but does perl know this and optimise it away ?) Out of which LIST-2 then (at each of the 32 iterations) we extract just 1 "random" element, by virtue of the [rand(62)] index into the list LIST-2. I am not sure immediately of the effect of the leading +(LIST-2), but it may have the effect of forcing some internal conversion of the elements of (LIST-2). At the end of the 32 iterations of map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 we have an array of 32 single-character elements. Which we then join into a 32-character string by means of the join(). I may be wrong, but at least intuitively, this does not seem to be an optimal way to obtain a 32-char long random key. Mathematically, I think such a string provides for 62 ** 32 combinations, which is .. 2,085924839766513752333849312 e+93 according to my pocket calculator. That may be more than the total number of atoms in the known Universe. Which I have also intuitively a tendency to consider a bit excessive, for generating a simple time-limited session key for a webapp. Note also that the fact that there are theoretically that many possible combinations, does not mean that all of them are equally likely. For that to be the case, rand() would have to return a series of really random responses, which we know it doesn't. If it’s properly seeded in the original code, it should either work or not work on all five servers. Not working on one out of the five makes me think maybe there’s some sort of weird caching issue. I agree, that the seed is the main issue. The code should insure that for each server process (+ perl interpreter), srand() is called once, whence that process starts (or the first time the webapp is run), and with a different seed for each process. (A BEGIN block with a seed based on the time (hi-res) may be a solution.) But the fact that it does not evidently work on one of the servers only, may be due to many factors, such as the rate at which already-keyed and not-already-keyed requests are hitting each server, their order, how many server processes there are to respond to the requests, and how long it takes to respond to one request. So it may also be that "it does not work" on all servers, but that it has only been so far noticed on the one. If all server processes on one server happen to use the same seed, then it depends on which server process handles the next unkeyed request. If it happens to be, for that server process, the n-th unkeyed request that it handles (and other server processes have already handled more than n requests before), then the key generated by this server process will duplicate one which has already been issued before, no matter how many different keys are theoretically possible. And whether this causes problems or not (or gets noticed), may only depend on whether the session which previously used the same key, has already concluded or not.
Re: $r->requires and register_auth_provider
Hi. I don't have anything very precise to tell you, but here is what I know : The AAA part has been significantly changed in Apache httpd 2.4, as compared to 2.2. Therefore I suspect - but I am not sure - that some corresponding changes had to be made in mod_perl, to adapt to these changes. One of the changes that I see when looking at the Apache 2.4 vs 2.2 on-line documentation (for Apache, not for mod_perl), concerns the syntax - and who handles - the "Require" directives. I also believe that the on-line mod_perl documentation does not yet reflect these changes, and it seems a bit hard to find an up-to-date documentation yet. But anyway, I just found this on CPAN : https://metacpan.org/source/MSCHOUT/Apache-AuthCookie-3.23/lib/Apache2_4/AuthCookie.pm That - along with the module name - seems to show a way to obtain the "Require" that you need. Why don't you give it a try ? Another way that I can think of, would be to use the Apache2::Directive module (http://perl.apache.org/docs/2.0/api/Apache2/Directive.html), to obtain the Require via the server's configuration tree. That should be independent of the specific Apache version being used. On 20.12.2015 03:35, Sergei Gerasenko wrote: Hello, I’m using mod_perl-2.0.8-10 and I’ve been googling for days for this info w/o any luck. I need to access the value for the Require directive in the apache configs. I need to access that info in my authorization handler (PerlAuthzHandler). It used to be that $r->requires provided that information, but it’s gone now according to the changelog. It has been replaced with register_auth_provider and according to this: perl -MModPerl::MethodLookup -e print_method register_auth_provider To use method 'register_auth_provider' add: use Apache2::RequestUtil (); … it should be in Apache2::RequestUtil. But I can’t find anything about that method in the description of Apache2::RequestUtil. Further, I get “undefined method” when I try to even mention it in my handler. I must be missing something really simple? Can somebody point me to a full example of using that method? Thanks! Sergei
"SetEnv/SetEnvIf" and mod_perl
Hi again.
Assuming this kind of configuration :
SetEnvIf Request_URI \.gif$ gif-image
SetHandler modperl
PerlResponseHandler MyNiftyModule
..
is there any way, in MyNiftyModule, to "get at" this "gif-image" variable ?
Such as, would I find it as $ENV{'gif-image'} ?
What kind of thing are these "Apache environment variables" anyway ?
I have been using them extensively within Apache itself, but I still can't quite figure
out on what plane they live. Clearly, they are not "environment variables" in the same
sense as "cgi-bin environment variables", and not the same thing either as what a
"PerlsetVar" does, so what are they ?
(And I realise that this is more of an Apache httpd question, but I figure that if someone
should be aware of the httpd internals, there is a good chance of finding such a person here).
Re: Apache2 filter
On 02.10.2015 10:19, James Smith wrote:
perl -cw sometimes throws errors with mod_perl code - as it isn't running in
the Apache
environment...
I get the same warning testing my output filter handler when running with -cw -
but it
works well in Apache...!
This begs for a follow-up question, which probably gets into rather arcane perl internals
but..
What does the fact of specifying an "attribute" such as
sub handler : FilterRequestHandler {
actually /do/ ?
When I wrote before that this was my first attempt at writing an Apache/mod_perl output
filter, I was not being entirely accurate. I did create and run such an output filter
before, defined as just
sub redir_filter {
..
}
but I was installing it at run-time, from a PerlAccessHandler module, via
$r->add_output_filter(\&redir_filter);
and that did not seem to be a problem.
But in this case, I would need to configure my filter in the Apache configuration, like in
this other example from the on-line mod_perl documentation :
PerlModule MyApache2::Underrun
PerlInputFilterHandler MyApache2::Underrun::filter
SetHandler modperl
PerlResponseHandler MyApache2::Underrun::response
So, would the presence/absence of the attribute have any effect on how it has to be
configured e.g. ?
On 10/1/2015 6:59 PM, A. Warnier wrote:
Hi.
I am trying to write an Apache2 request filter.
According to the online tutorial
(http://perl.apache.org/docs/2.0/user/handlers/filters.html#Output_Filters). I
have this
so far :
package MyFilter;
...
use base qw(Apache2::Filter);
...
use constant BUFF_LEN => 4096;
sub handler : FilterRequestHandler {
my $f = shift;
my $content = '';
while ($f->read(my $buffer, BUFF_LEN)) {
$content .= $buffer;
}
}
but when I compile this :
aw@arthur:~/tests$ perl -cw PAGELINKS.pm
Invalid CODE attribute: FilterRequestHandler at PAGELINKS.pm line 50.
BEGIN failed--compilation aborted at PAGELINKS.pm line 50.
aw@arthur:~/tests$
platform data (from Apache log) :
[Tue Sep 01 06:25:10 2015] [notice] Apache/2.2.16 (Debian) DAV/2 SVN/1.6.12
mod_jk/1.2.30 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1 configured
--
resuming normal operations
There are already many other mod_perl modules of all kinds running on that same
server
(but not filters).
What I am missing ?
André
Re: [Rusonyx #1410025]: Re: Enquiry about mod_perl project state
Hi. Isn't anyone going to do anything about (kindly) this Russian auto-responder ? Like, unsubscribe it from the list ? Rusonyx Support Team wrote: Randolf Richardson, Вы написали в компанию Русоникс и это письмо является автоматическим подтверждением того, что Ваша заявка поступила в очередь на обработку. Мы ответим на Ваш запрос по возможности максимально быстро. ID Заявки: 1410025 Тема: Re: Enquiry about mod_perl project state Отдел: Support Тип: Issue Статус: Open Приоритет: Medium С уважением ООО Русоникс www.rusonyx.ru Rusonyx -- Портал технической поддержки: https://support.rusonyx.ru/index.php?
Re: Apache / mod_perl / Perl under Windows
Michael Lackhoff wrote: Am 03.07.2015 um 15:55 schrieb André Warnier: Grateful for any insight. No real insight but a working setup for development which runs from USB-stick and on about any system from XP 32bit to Windows 7 64bit (sorry, no experience with Windows server, all my servers run Linux, Windows is just nice for development): - httpd-2.2.29-win32-ssl_0.9.8.zip from apachelounge I cannot see exactly this version any longer on their site but I think it is a VC9 build so https://www.apachelounge.com/download/win32/binaries/httpd-2.2.29-win32-ssl_0.9.8-VC9.zip should be similar - http://strawberryperl.com/download/5.20.2.1/strawberry-perl-no64-5.20.2.1-32bit-portable.zip Important: use the "no USE_64_BIT_INT" version - http://people.apache.org/~stevehay/mod_perl-2.0.8-strawberryperl-5.20.1.1-32bit-no64.zip This setup works quite well for me. Thank you for another combination which works. What I am trying to figure out though, is what are the factors which make it so that this combination (and the one I mentioned before) work, as opposed to others which don't ? There are 3 parts, each with the following variables : - the version of /that/ package (e.g. Apache httpd 2.2.x, or mod_perl 2.0.8) - the architecture : 32-bit or 64-bit - the compiler with which that package is compiled (VC 9, 10, 11 or gcc e.g.) Which factors must match which, to have a chance of a working combination ? I am quite sure that I tried together : - an Apache 2.2.x from ApacheLounge (compiled with VC) - Strawberry perl 5.18 32-bit - mod_perl 2.0.8 32-bit no 64 strawberry from Steve Hay and that I could never get this to work under Windows 2008 (64-bit). That's why I switched to activeperl 5.18 and mod_perl 2.0.8 for ActivePerl, but Strawberry-perl would have definitely been my preference, as it is what I usually recommend nowadays to my customers, for various reasons. There are just a bit too many factor combinations possible, to figure this out easily by myself, so if someone has a clue as to what matters and what doesn't.. P.S. In my defense, I was trying to figure this out at a customer, under some time pressure, by comparison between a working Linux Debian server (English), a working Windows 2003 Server 32-bit (German), and a non-working Windows 2008 Server 64-bit (Dutch), each with its own variety of localised error messages, and each in a different geographical location, so it may be that at some point I lost my usual calm and rational investigative approach here.. Long live Linux Debian.
Apache / mod_perl / Perl under Windows
Hi. Can someone help clearing my confusion (again) as to what kind of Apache / mod_perl / Perl combination works under Windows (32-bit and 64-bit) ? I thank Steve Hay many times for providing numerous versions of mod_perl for numerous versions of platforms and numerous versions of Active and Strawberry Perl. And I finally managed to have the following combination working under Windows server 2008 64-bit R2 : - Apache 2.2 from : http://www.apachelounge.com/download/win64/binaries/httpd-2.2.29-win64.zip - ActivePerl 5.18.4.1804 from : http://www.activestate.com/activeperl/downloads/thank-you?dl=http://downloads.activestate.com/ActivePerl/releases/5.18.4.1804/ActivePerl-5.18.4.1804-MSWin32-x64-298913.msi - mod_perl 2.0.8 from : http://people.apache.org/~stevehay/mod_perl-2.0.8-activeperl-5.18.4.1803-x64.zip but before that, I spent most of a day fighting with various versions of all the above and obscure Windows error messages ranging from "the application is not a Win32 application" to "the Service started but terminated unexpectedly" to .. nothing. One problem was (I suppose, but finally I am totally unsure of) that I initially tried to use a Strawberry Perl (which seems to tell me that it is compiled with gcc), but could never find an Apache 2.2 binary similarly compiled with gcc. Anyway, I am quite confused now again as to what must match what. Grateful for any insight. André
Re: Apache 2.4 and AAA
Kevin A. McGrail wrote: On 5/29/2015 1:52 PM, André Warnier wrote: Kevin A. McGrail wrote: On 5/29/2015 1:20 PM, André Warnier wrote: Over the years, I have created and modified and re-modified my own Apache/mod_perl authentication module, which was originally derived from Apache(2?)::AuthCookie (pilfered would be the correct term I guess). It currently runs up to Apache 2.2, but I have heard/read in various places that the Apache AAA interface had been changed significantly in 2.4. I figure that I should thus start updating my module, before all my customers update their Apache and make my module obsolete. But although I have seen many warnings about the changes, I have not really see yet any real outline of the changes in mod_perl AAA API calls, that would likely have to be made to accomodate this. Would anyone have more info or pointers on that general subject ? Sounds like a good time to read http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html and to play with the 2.0.9-rc2 (they discussed releasing it today...) Beyond that, I don't know that anyone will have any specific input without seeing the module and what errors you are having with 2.4/mp2.0.9rc1 or rc2. Thank you for the pointer. I read it, but that is of the same order as what I was mentioning above : it discusses the internal changes to Apache httpd, from the point of view of, for example, the developers of mod_perl themselves. My own module does not interface directly with Apache at the C level. I merely use the methods/functions available in mod_perl, as described here for example : http://perl.apache.org/docs/2.0/api/Apache2/Access.html Have these functions changed ? And if yes, do you know if any updated mod_perl documentation exists about that ? Or, better yet, has the interface to these functions not changed, the dirty work having already been done by the mod_perl developers to make this update totally transparent (which of course I would love) ? My module hasn't come up with any error yet with Apache 2.4, for the simple reason that I have not tried it yet with Apache 2.4. I am just trying to be prepared. Well, if you look at https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7197 and https://svn.apache.org/viewvc?view=revision&revision=1681228, you'll see how the documentation rippled down from 2.4 to MP and how I implemented $c->client_ip instead of $c->remote_ip So while I understand you are writing in perl, the documentation at http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html about the changes is a good starting point. It's what I used to make my first pass at a fix for the code on SpamAssassin that used it. Beyond that, support for httpd 2.4 in mod_perl is in release candidate with the first release candidate about 1 week old so I'm not aware of more documentation. But without A) seeing your module or B) having any errors to comment on, not really sure there is much more to go on. Anyway to answer your issue, looking at Apache2::Access in mod_perl 2.0.9rc1, my belief is that it's essentially going to provide a buffer between your version of Apache so those calls won't change whether it's 2.2 or 2.4. Highly recommend you compile 2.0.9 rc1 or rc2 and a version of 2.4 and test it. If you find an issue, it might even be fixable before 2.0.9 is released which is the first official MP support for httpd 2.4. regards, KAM Thank you.
Re: Apache 2.4 and AAA
Kevin A. McGrail wrote: On 5/29/2015 1:20 PM, André Warnier wrote: Over the years, I have created and modified and re-modified my own Apache/mod_perl authentication module, which was originally derived from Apache(2?)::AuthCookie (pilfered would be the correct term I guess). It currently runs up to Apache 2.2, but I have heard/read in various places that the Apache AAA interface had been changed significantly in 2.4. I figure that I should thus start updating my module, before all my customers update their Apache and make my module obsolete. But although I have seen many warnings about the changes, I have not really see yet any real outline of the changes in mod_perl AAA API calls, that would likely have to be made to accomodate this. Would anyone have more info or pointers on that general subject ? Sounds like a good time to read http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html and to play with the 2.0.9-rc2 (they discussed releasing it today...) Beyond that, I don't know that anyone will have any specific input without seeing the module and what errors you are having with 2.4/mp2.0.9rc1 or rc2. Thank you for the pointer. I read it, but that is of the same order as what I was mentioning above : it discusses the internal changes to Apache httpd, from the point of view of, for example, the developers of mod_perl themselves. My own module does not interface directly with Apache at the C level. I merely use the methods/functions available in mod_perl, as described here for example : http://perl.apache.org/docs/2.0/api/Apache2/Access.html Have these functions changed ? And if yes, do you know if any updated mod_perl documentation exists about that ? Or, better yet, has the interface to these functions not changed, the dirty work having already been done by the mod_perl developers to make this update totally transparent (which of course I would love) ? My module hasn't come up with any error yet with Apache 2.4, for the simple reason that I have not tried it yet with Apache 2.4. I am just trying to be prepared. Thanks André
Apache 2.4 and AAA
Hi. Over the years, I have created and modified and re-modified my own Apache/mod_perl authentication module, which was originally derived from Apache(2?)::AuthCookie (pilfered would be the correct term I guess). It currently runs up to Apache 2.2, but I have heard/read in various places that the Apache AAA interface had been changed significantly in 2.4. I figure that I should thus start updating my module, before all my customers update their Apache and make my module obsolete. But although I have seen many warnings about the changes, I have not really see yet any real outline of the changes in mod_perl AAA API calls, that would likely have to be made to accomodate this. Would anyone have more info or pointers on that general subject ? Thanks in advance André
Re: mod_perl and apache 2.4
Hi. I honestly don't know if this will help you, because I have no idea about FreeBSD. But what I can tell you, is that I am running Apache 2.2 and mod_perl 2 succesfully on multiple servers, under various versions of Windows and under various versions of Linux, without any problems whatsoever. So it looks at least that if you are having a problem, it should be something specific to the FreeBSD environment that you are using, and not about the Apache 2.2 / mod_perl 2 combination in general. GLG wrote: Thanks everyone for earlier replies, I now have Apache22 installed, but I am unable to start it with mod_perl2. From my research, I am being led to believe that my mod_perl2 installation may be faulty, due to the fact that Libtool needs to be patched, as it incorrectly identifies FreeBSD 10 as FreeBSD 1.x, and that can be the source of my problems (Undefined symbol "modperl_io_perlio_restore_stdout"). This information is several months old however. Does anyone know if the above is fixed with Libtool 2.4.6? Can anyone here successfully load mod_perl.so into apache22, or am I beating a dead horse? Thanks again, GLG * GLG wrote: Date: Thu, 16 Apr 2015 10:22:23 -0400 From: GLG To: modperl@perl.apache.org Subject: mod_perl and apache 2.4 X-Mailer: Microsoft Office Outlook 12.0 Hello List, I am new here. In the process of moving several websites to a new server running FreeBSD 10 and Apache 2.4. This needs to happen quickly. Unless I am mistaken, it would appear that there is currently no solution as far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a version 2.0.9 out?). If indeed that is the case, then I must downgrade to a previous version of Apache. But before I do, I'd like confirmation that my assumptions are correct. Hopefully someone can answer this or suggest a better alternative. I've tried applying a previously released patch, and I've also tried faking it as described here. http://lists.freebsd.org/pipermail/freebsd-ports/2014-August/094405.html But in both cases, mod_perl will not build. Please see partial output below. Thank you, Gina /usr/ports/www/mod_perl2 # make build ===> ap24-mod_perl2-2.0.8_2,3 depends on package: p5-BSD-Resource>=0 - not found ===>Verifying install for p5-BSD-Resource>=0 in /usr/ports/devel/p5-BSD-Resource ===> Installing for p5-BSD-Resource-1.2907 ===> p5-BSD-Resource-1.2907 depends on file: /usr/local/bin/perl5.18.4 - found ===> Checking if p5-BSD-Resource already installed ===> Registering installation for p5-BSD-Resource-1.2907 as automatic pkg-static: Unable to access file /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5. 18/mach/BSD/Resource.pm: No such file or directory pkg-static: Unable to access file /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5. 18/mach/auto/BSD/Resource/.packlist: No such file or directory pkg-static: Unable to access file /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5. 18/mach/auto/BSD/Resource/Resource.so: No such file or directory pkg-static: Unable to access file /usr/ports/devel/p5-BSD-Resource/work/stage/usr/local/lib/perl5/site_perl/5. 18/mach/auto/BSD/Resource/_find_prio.al: No such file or directory __ * * Interactive Multimedia - Internet Management * * * * Virtual Reality - Application Programming * * * 3D Net Productions 3dnetproductions.com *
Re: Large File Download
Randolf Richardson wrote: I know that it's possible(and arguably best practice) to use Apache to download large files efficiently and quickly, without passing them through mod_perl. However, the data I need to download from my application is both dynamically generated and sensitive so I cannot expose it to the internet for anonymous download via Apache. So, I'm wondering if mod_perl has a capability similar to the output stream of a java servlet. Specifically, I want to return bits and pieces of the file at a time over the wire so that I can avoid loading the entire file into memory prior to sending it to the browser. Currently, I'm loading the entire file into memory before sending it and Is this possible with mod_perl and, if so, how should I go about implementing it? Yes, it is possible -- instead of loading the entire contents of a file into RAM, just read blocks in a loop and keep sending them until you reach EoF (End of File). You can also use $r->flush along the way if you like, but as I understand it this isn't necessary because Apache HTTPd will send the data as soon as its internal buffers contain enough data. Of course, if you can tune your block size in your loop to match Apache's output buffer size, then that will probably help. (I don't know much about the details of Apache's output buffers because I've not read up too much on them, so I hope my assumptions about this are correct.) One of the added benefits you get from using a loop is that you can also implement rate limiting if that becomes useful. You can certainly also implement access controls as well by cross-checking the file being sent with whatever internal database queries you'd normally use to ensure it's okay to send the file first. You can also : 1) write the data to a file 2) $r->sendfile(...); 3) add a cleanup handler, to delete the file when the request has been served. See here for details : http://perl.apache.org/docs/2.0/api/Apache2/RequestIO.html#C_sendfile_ For this to work, there is an Apache configuration directive which must be set to "on". I believe it is called "UseSendFile". Essentially what senfile() does, is to delegate the actual reading and sending of the file to Apache httpd and the underlying OS, using code which is specifically optimised for this purpose. It is much kore efficient than doing this in a read/write loop by yourself, at the cost of having less fine control over the operation.
Re: Disallow path info
Szekeres Jr., Edward wrote:
I am not sure why something as simple as this would be considered "dicing and slicing",
simply blocks any requests with "path[any character]info" in them
I already apologised for that comment.
RewriteEngine On
RewriteCond %{REQUEST_URI} ^.*(path.info).* [NC]
RewriteRule ^(.*)$ - [F]
What would you put instead of the (path.info) above ?
-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: Tuesday, March 24, 2015 11:12 AM
To: mod_perl list
Subject: Re: Disallow path info
On Tue, Mar 24, 2015 at 3:44 AM, André Warnier wrote:
You know, I am slowly getting the feeling that by dicing and slicing the
URLs and fixing up things afterward, you are setting yourself up for some
major headeaches later on, when something changes and/or someone needs to
figure out what is going on.
Umm, no I am not dicing and slicing URLs and fixing up things afterwards.
If I tried to solve this problem using rewrite module, that would be
dicing and slicing and I'm not confident I would get the regex right.
If I tried to modify all my scripts to handle path_info and alter the
URLs inside the returned HTML by, e.g., prepend ../ for however many
parts are in the path info *that* would really be dicing and slicing
and I would probably mess up somewhere.
No, I'm not doing either of those. I'm doing a 3-line
PerlFixupHandler to return 404 if path_info is set, which is the
perfect fix for the fact that ModPerl ignores "Accept PathInfo off"
apache directive for some reason.
It may be time to reconsider the issue "top-down", and maybe see if there is
not a "more standard" way of achieving what you wanted to achieve in the
first place (which I honestly have lost track of by now).
I already made the issue very clear. Just go read my first email.
The only "more standard" way of achieving what I want would be for
ModPerl to stop ignoring the "AcceptPathInfo off" apache directive.
I mean, mod_perl is great, in that it allows one to do just that kind of
thing, at a relatively deep level within the Apache logic itself. But there
lies also the danger of incrementally building up your very own webserver
with its very own logic, which at some point does not match anymore what a
HTTP-compliant webserver should do in some particular circumstance, and
becomes very fragile and difficult to maintain or adapt to some new quirk
which would appear on the WWW.
Umm, no. I'm not using modperl to accomplish some non-standard thing.
An HTTP-compliant webserver is free to allow or disallow paths like
http://mysite.example.com/myscript.pl/path/info, and Apache already
supports either allowing or disallowing that, and I can achieve
exactly what I want without ModPerl using the "AcceptPathInfo off"
directive.
It is when I add ModPerl to the mix that the problem comes back
because ModPerl ignores "AcceptPathInfo off" and that is a problem
with ModPerl not a problem with what I am trying to achieve, so fixing
a problem caused by ModPerl with a ModPerl fixup handler makes perfect
sense.
For example, I believe that it is entirely HTTP-compliant for a URL to
invoke a script and nevertheless pass it path-info information at the same
time, for the script to use in some way. In this particular case, should it
not be the script which discards the unwanted path_info if it doesn't want
it ? I am not saying that this is the "right" answer, but it is maybe worth
pondering, before introducing additional webserver logic which might have
unintended side-effects in other cases.
I believe you are right, it is entirely HTTP-compliant to support
path-info. But I believe it is also entirely HTTP-compliant to not
support it.
My scripts already discard path_info, but that doesn't solve the
problem I explained, which is that if you enter
http://mysite.example.com/myscript.pl/path/info, then if my script
returns HTML that includes then your web browser will try to download the
css at http://mysite.example.com/myscript.pl/path/info/css/default.css,
which is wrong and will return HTML from my script again instead of
the actual css which is at http://mysite.example.com/css/default.css.
path-info may work for you, but it doesn't work for me, and I don't
need it and I don't use it and I don't want it and it is entirely
legitimate for me to not support it.
Phillip
Re: Disallow path info
Phillip Hellewell wrote: On Tue, Mar 24, 2015 at 3:44 AM, André Warnier wrote: You know, I am slowly getting the feeling that by dicing and slicing the URLs and fixing up things afterward, you are setting yourself up for some major headeaches later on, when something changes and/or someone needs to figure out what is going on. Umm, no I am not dicing and slicing URLs and fixing up things afterwards. If I tried to solve this problem using rewrite module, that would be dicing and slicing and I'm not confident I would get the regex right. If I tried to modify all my scripts to handle path_info and alter the URLs inside the returned HTML by, e.g., prepend ../ for however many parts are in the path info *that* would really be dicing and slicing and I would probably mess up somewhere. No, I'm not doing either of those. I'm doing a 3-line PerlFixupHandler to return 404 if path_info is set, which is the perfect fix for the fact that ModPerl ignores "Accept PathInfo off" apache directive for some reason. It may be time to reconsider the issue "top-down", and maybe see if there is not a "more standard" way of achieving what you wanted to achieve in the first place (which I honestly have lost track of by now). I already made the issue very clear. Just go read my first email. The only "more standard" way of achieving what I want would be for ModPerl to stop ignoring the "AcceptPathInfo off" apache directive. I mean, mod_perl is great, in that it allows one to do just that kind of thing, at a relatively deep level within the Apache logic itself. But there lies also the danger of incrementally building up your very own webserver with its very own logic, which at some point does not match anymore what a HTTP-compliant webserver should do in some particular circumstance, and becomes very fragile and difficult to maintain or adapt to some new quirk which would appear on the WWW. Umm, no. I'm not using modperl to accomplish some non-standard thing. An HTTP-compliant webserver is free to allow or disallow paths like http://mysite.example.com/myscript.pl/path/info, and Apache already supports either allowing or disallowing that, and I can achieve exactly what I want without ModPerl using the "AcceptPathInfo off" directive. It is when I add ModPerl to the mix that the problem comes back because ModPerl ignores "AcceptPathInfo off" and that is a problem with ModPerl not a problem with what I am trying to achieve, so fixing a problem caused by ModPerl with a ModPerl fixup handler makes perfect sense. For example, I believe that it is entirely HTTP-compliant for a URL to invoke a script and nevertheless pass it path-info information at the same time, for the script to use in some way. In this particular case, should it not be the script which discards the unwanted path_info if it doesn't want it ? I am not saying that this is the "right" answer, but it is maybe worth pondering, before introducing additional webserver logic which might have unintended side-effects in other cases. I believe you are right, it is entirely HTTP-compliant to support path-info. But I believe it is also entirely HTTP-compliant to not support it. My scripts already discard path_info, but that doesn't solve the problem I explained, which is that if you enter http://mysite.example.com/myscript.pl/path/info, then if my script returns HTML that includes then your web browser will try to download the css at http://mysite.example.com/myscript.pl/path/info/css/default.css, which is wrong and will return HTML from my script again instead of the actual css which is at http://mysite.example.com/css/default.css. path-info may work for you, but it doesn't work for me, and I don't need it and I don't use it and I don't want it and it is entirely legitimate for me to not support it. Sorry, I did not mean to offend you or attack your strategy here. I was just trying to alert you to possible pitfalls, for having been there myself before : you start with a tweak to achieve one particular goal, and then you find that in one case it doesn't work as expected, so you add another tweak, and before you know it, you find yourself in a hopeless spiral of tweak over tweak.. I believe that I also got a bit confused, and mixed up memories of a previous post to the list (entitled "How Do I change the Document Root Per Request"), and thought that your post was a follow-up on that one (which would have made it a lot of tweaks). Sorry again.
Re: Disallow path info
Phillip Hellewell wrote:
Good news. I got a helpful tip from a Dr James Smith to use a
PerlFixupHandler that looks like this:
package My::Fixup;
use strict;
use warnings;
use utf8;
use Apache2::Const qw(OK NOT_FOUND);
sub handler {
my $r = shift;
return NOT_FOUND if $r->path_info;
return OK;
}
1;
It worked just great!
Phillip
You know, I am slowly getting the feeling that by dicing and slicing the URLs and fixing
up things afterward, you are setting yourself up for some major headeaches later on, when
something changes and/or someone needs to figure out what is going on.
It may be time to reconsider the issue "top-down", and maybe see if there is not a "more
standard" way of achieving what you wanted to achieve in the first place (which I honestly
have lost track of by now).
I mean, mod_perl is great, in that it allows one to do just that kind of thing, at a
relatively deep level within the Apache logic itself. But there lies also the danger of
incrementally building up your very own webserver with its very own logic, which at some
point does not match anymore what a HTTP-compliant webserver should do in some particular
circumstance, and becomes very fragile and difficult to maintain or adapt to some new
quirk which would appear on the WWW.
For example, I believe that it is entirely HTTP-compliant for a URL to invoke a script and
nevertheless pass it path-info information at the same time, for the script to use in some
way. In this particular case, should it not be the script which discards the unwanted
path_info if it doesn't want it ? I am not saying that this is the "right" answer, but it
is maybe worth pondering, before introducing additional webserver logic which might have
unintended side-effects in other cases.
André
Re: Are there windows binaries for 5.20?
Hi. Never mind all the stuff below (although it may end up helping another compiler-dummy like me). I now got the reason : on my laptop (and also on the other Windows machine) the version of Strawberry Perl was 5.18.4.1 32-bit, but it was /not/ the "no-64-bit-ints" specific version found here : http://strawberryperl.com/releases.html section : "5.18.4.1 / 32bit - without USE_64_BIT_INT" Once I corrected that (and re-installed the rest as per below), the error went away. Many, many thanks for the binaries, and sorry for the noise. André André Warnier wrote: Hi. I am a bit confused now. I have downloaded http://people.apache.org/~stevehay/mod_perl-2.0.8-strawberryperl-5.18.4.1-32bit-no64.zip (for which many thanks anyway, no matter what follows). I tried to use that first on my old and venerable Windows XP 32-bit SP3 laptop. When trying to compile a small test module (see below), I got a compilation error : C:\develop\06_SVN\AP2lib\trunk\modlib\AM>perl -cw Basket.pm panic: no address for 'Apache2::Const::compile' in 'Const.xs' at C:/strawberry/p erl/lib/XSLoader.pm line 92. Compilation failed in require at Basket.pm line 9. BEGIN failed--compilation aborted at Basket.pm line 9. Line 9 is : use Apache2::Const -compile => qw(REDIRECT); or just use Apache2::Const; But this (old and venerable) laptop is also quite messy, so I didn't trust it all that much. I thus tried this all again on a much more recent and clean 64-bit Windows 7 Pro workstation, on which there is installed : - StrawberryPerl 5.18 32-bit , in c:\strawberry. - Apache 2.2.29 32-bit (ApacheLounge : https://www.apachelounge.com/download/win32/binaries/httpd-2.2.29-win32.zip), in c:\apache2 The full versions of both can be found in the attached file "test_mp2_compile.txt". Following the instructions in the mod_perl zip file above, I copied - the zip-file's "Apache2" directory over C:\Apache2 - the zip-file's "Strawberry" directory over C:\strawberry Then I tried to compile the small partial module again (source shown also in the attached text file). And I first got the errors successively shown in the attachments screenshots. The first (error_01) popup seems to tell me that the file "libaprutil-1.dll" isn't found, after which I get some strange perl compiler error. The file is there however, as shown in error_03.jpg. That is apparently solved by adding "C:\apache2\bin" to the system PATH variable (which the ApacheLounge installation doesn't do). But then, trying to compile the test module again, the popup doesn't occur anymore, but I get another compile error as shown in "error_04.jpg", which is the same error as on my old and venerable and messy laptop (which seems thus to be not so totally messy after all, at least not in that respect). What am I missing (on both systems) ? TIA André Steve Hay wrote: On 15 Feb 2015 16:37, "Michael Lackhoff" wrote: Am 15.02.2015 um 17:15 schrieb Steve Hay: I will put some new ones up at http://people.apache.org/~stevehay/ soon, by they'll be 64-bit only for now. Thanks! Though it might be difficult to get everything else I need in 64bit, too. If you want 32-bit then the easiest way is to build it yourself using a perl that you built yourself with the same compiler. Is there a recommended compiler? I use Strawberry perl, do you know which compiler is used for that perl? As you say, it would be better to use the same. And I would like to stick to it because there are so many binaries of difficult modules already included. Unfortunately you'll need to use VC++ for now because mod_perl doesn't currently support gcc/dmake (which is what both StrawberryPerl and ActivePerl now use). I hope to fix that soon, though... You just need to get APXS from https://svn.apache.org/repos/asf/perl/apxs/trunk and run something like perl Configure.pl --with-apache2=C:\apache --with-apache-prog=httpd.exe do I also have to compile apache myself? Or just put the src under c:\apache? A prebuilt one, say from Apache Lounge, using the same VC++ should be ok, but I build Apache from source too just to rule out any possible compatibility problems. It's the binary installation, not the source tree, that you need in C:\apache in my example.
Re: Are there windows binaries for 5.20?
Steve Hay wrote: ... Unfortunately you'll need to use VC++ for now because mod_perl doesn't currently support gcc/dmake (which is what both StrawberryPerl and ActivePerl now use). I hope to fix that soon, though... I'll be eternally grateful too, when you get to that point. I am also desperately looking for an Apache 2.2 / mod_perl 2 binary based on Strawberry Perl 5.18 *32-bit*, which (of course) seems to be just the one missing in your (great) list at http://people.apache.org/~stevehay/.. Sniff..
Re: File Corrupt when download with ModPerl scripts
Michel,
from what you describe below, this sounds very unlikely to be a perl or
mod_perl issue.
If I have to make a guess, I would say that what you download via perl/mod_perl is just
not the same image file as what you think you download. Maybe it is a thumbnail version
of the original image ?
For start, add this after "binmode($in);"
warn "About to return file <$fname>, size : " . -s $fname;
and then have a look at your webserver error log, to see if it is what you
expect.
Michel Jansen wrote:
Hi There,
Somehow images get corrupted when i read and then download them with a
modperl script using File::Read or File::Slurp. The images are not
really broken but they get blurred and dont look like before they are
uploaded. When i download them directly from the webserver directory
where they are stored they are ok.
I have also tried the script below but no success.
<-->
print $args->{base}->{CGI}->header( -type => $mimetype, -attachment
=> $document );
my $fname = $file;
open my $in, q{<}, $fname or die qq{Could not open file <$fname>: $!};
binmode($in);
open my $out, q{>&STDOUT} or die qq{Cant dup STDOUT: $!};
binmode($out);
$out->autoflush(1);
my ($more, $buf);
do{
$more = read $in, $buf, 4096;
print $out $buf;
} while $more;
close $out or die $!;
close $in or die $!;
<-->
Any hints that can help me out?
Thanx in advance!
Michel
Re: mod_perl installed via yum but not used by application (RedHat 6.5 Apache 2.2.15 mod_perl 2.0.4)
BOUX Frederik wrote:
Hello,
I am using OTRS on a RedHat 6.5 with apache2 and mod_perl2. We are using these
packages (yum info feedback):
Installed Packages
Name: httpd
Arch: x86_64
Version : 2.2.15
Release : 39.el6
Name: mod_perl
Arch: x86_64
Version : 2.0.4
Release : 11.el6_5
We noticed a performance difference with the Development server. I can see in
htop that the apache user is spawning /usr/bin/perl processes to run all the
perl scripts instead of handling them in an httpd process. So I placed the
following script in the same directory as my index.pl to see if mod_perl was
being used:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "Server's environment\n";
foreach ( keys %ENV ) {
print "$_\t$ENV{$_}\n";
}
Dev shows these two variables that are completely missing on Sandbox:
MOD_PERL_API_VERSION 2
MOD_PERL mod_perl/2.0.4
So I'm pretty sure mod_perl isn't being used . But as far as I can tell
everything is configured:
1) /etc/httpd/conf.d/perl.conf contains the line: LoadModule perl_module
modules/mod_perl.so
2) /etc/httpd/conf/httpd.conf contains an Include: Include conf.d/*.conf
3) this is the default .conf from OTRS but I can't find a mistake:
# Setup environment and preload modules
Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl
# Reload Perl modules when changed on disk
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
# general mod_perl2 options
#ErrorDocument 403 /otrs/customer.pl
ErrorDocument 403 /otrs/index.pl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
PerlOptions +SetupEnv
Order allow,deny
Allow from all
= 2.4>
Require all granted
Order allow,deny
Allow from all
# mod_perl2 options for GenericInterface
PerlOptions -ParseHeaders
And yet the module is loaded:
[user@server httpd]$ httpd -M | grep perl
Syntax OK
perl_module (shared)
[user@server httpd]$ httpd -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
Anyone who can spot a mistake or who has additional steps to troubleshoot why
mod_perl isn't being used?
Just a little comment : when you restart your server, the first line in the error log
should clearly show if mod_perl is included or not.
Also, if it isn't, then all the mod_perl specific configuration lines above should trigger
an Apache error when it starts (and it would not start).
Errors such as
"PerlOptions" : unknown directive at line xxx ...
Unless your server actually starts with another configuration file set than the one you
think..
Re: undefined
Bill Moseley wrote:
I'm printing like this:
my $octets = 'Быстрая коричневая лиса चाँद पर';
$r->log->warn( $octets );
$r->log->warn( Encode::decode_utf8( $octets ) );
print STDERR $octets;
But what I get in the logs is this:
[Tue Sep 23 09:12:07 2014] [warn] [client 10.5.24.82]
\xd0\x91\xd1\x8b\xd1\x81\xd1\x82\xd1\x80\xd0\xb0\xd1\x8f
\xd0\xba\xd0\xbe\xd1\x80\xd0\xb8\xd1\x87\xd0\xbd\xd0\xb5\xd0\xb2\xd0\xb0\xd1\x8f
\xd0\xbb\xd0\xb8\xd1\x81\xd0\xb0
\xe0\xa4\x9a\xe0\xa4\xbe\xe0\xa4\x81\xe0\xa4\xa6 \xe0\xa4\xaa\xe0\xa4\xb0
[Tue Sep 23 09:12:07 2014] [warn] [client 10.5.24.82]
\xd0\x91\xd1\x8b\xd1\x81\xd1\x82\xd1\x80\xd0\xb0\xd1\x8f
\xd0\xba\xd0\xbe\xd1\x80\xd0\xb8\xd1\x87\xd0\xbd\xd0\xb5\xd0\xb2\xd0\xb0\xd1\x8f
\xd0\xbb\xd0\xb8\xd1\x81\xd0\xb0
\xe0\xa4\x9a\xe0\xa4\xbe\xe0\xa4\x81\xe0\xa4\xa6 \xe0\xa4\xaa\xe0\xa4\xb0
Быстрая коричневая лиса चाँद पर
So you see (if your mail client allows) bypassing $r->log and printing
directly to STDERR works as I'd like. But I'd like to use $r->log for
logging.
Is this mod_perl doing the mapping?
Here's full output and the httpd.conf to reproduce:
$ httpd -d $(pwd) -f httpd_perl_sections.conf -k start; tail -f error.log
[Tue Sep 23 09:11:56 2014] [notice] Apache/2.2.15 (Unix) mod_perl/2.0.7
Perl/v5.14.2 configured -- resuming normal operations
Hey we are here
[Tue Sep 23 09:12:07 2014] [warn] [client 10.5.24.82] this is a warning
[Tue Sep 23 09:12:07 2014] [warn] [client 10.5.24.82]
\xd0\x91\xd1\x8b\xd1\x81\xd1\x82\xd1\x80\xd0\xb0\xd1\x8f
\xd0\xba\xd0\xbe\xd1\x80\xd0\xb8\xd1\x87\xd0\xbd\xd0\xb5\xd0\xb2\xd0\xb0\xd1\x8f
\xd0\xbb\xd0\xb8\xd1\x81\xd0\xb0
\xe0\xa4\x9a\xe0\xa4\xbe\xe0\xa4\x81\xe0\xa4\xa6 \xe0\xa4\xaa\xe0\xa4\xb0
[Tue Sep 23 09:12:07 2014] [warn] [client 10.5.24.82]
\xd0\x91\xd1\x8b\xd1\x81\xd1\x82\xd1\x80\xd0\xb0\xd1\x8f
\xd0\xba\xd0\xbe\xd1\x80\xd0\xb8\xd1\x87\xd0\xbd\xd0\xb5\xd0\xb2\xd0\xb0\xd1\x8f
\xd0\xbb\xd0\xb8\xd1\x81\xd0\xb0
\xe0\xa4\x9a\xe0\xa4\xbe\xe0\xa4\x81\xe0\xa4\xa6 \xe0\xa4\xaa\xe0\xa4\xb0
Быстрая коричневая лиса चाँद पर
$ cat httpd_perl_sections.conf
LoadModule perl_module
/home/bill/perl5/perlbrew/perls/perl-5.14.2/usr/lib64/httpd/modules/mod_perl.so
LoadModule mime_module modules/mod_mime.so
ErrorLog error.log
TypesConfig /etc/mime.types
PidFile apache.pid
{
package Foo;
use strict;
use warnings;
use Apache2::RequestRec;
use Apache2::RequestIO;
use Encode;
my $octets = 'Быстрая коричневая лиса चाँद पर';
sub handler {
my $r = shift;
print STDERR "Hey we are here\n";
$r->log->warn( 'this is a warning' );
$r->log->warn( $octets );
$r->log->warn( Encode::decode_utf8( $octets ) );
print STDERR $octets;
$r->content_type('text/plain');
$r->print( "hello world\n" );
return Apache2::Const::OK();
}
}
Listen 9090
SetHandler modperl
PerlResponseHandler Foo
Hi.
First, the subject chosen for your email is not going to be much help for someone
searching the list archives later. Even "Быстрая коричневая лиса" would have been better.
And second, a "what if.." :
What if you start Apache under a UTF-8 "locale" ?
(does it then still escape the non-iso-8859-1 characters in the log ?)
Re: Shared Dirty memory of Apache parent process
Hi. This is a bit beside your question below (for which I do not know the answer anyway). But if it is the case - that you have a number of Apache child processes which all need at start a certain initial table of data of 100-200 MB in size - that each of these children is going to modify that table over time (his own copy of it) - and that the number of child processes of Apache varies over time (which it does not necessarily have to do, but that is what you seem to be saying) Then, if you imagine having at some point 50 child processes, you are going to need something like 50 x 200 MB = 10 GB of memory. That's a lot of memory. And presumably, the biggest part of that is in fact the same, for all the children. So, should you not consider having a separate process which holds a single common table, shared with all the Apache children, and which they all consult and/or modify, over (for example) a TCP connection with that separate process ? Something like "memcached" for instance ? You would save yourself (roughly) 10 GB - 200 MB = 9.8 GB of memory. Even considering the low cost of memory today, you would still save yourself having to *write* 200 MB of memory 49 times (at least), which takes a considerable amount of time. Nageswara rao Gurram wrote: Hi, I am modifying(infact intializing) the global variable declared in start up with child processes..When every child process tries to modify it I think it should come as private memory of child.. But I am wondering why shared dirty memory of parent process is increasing every time child tries to modify it.. This is making next child of parent is getting created with much more shared memory ? Should I leave it or worry about it ? As even if RSS of all(combined) apache processes are increasing if I consider shared dirty in it, it will definitely looks smaller. On Tue, Sep 16, 2014 at 10:10 PM, Perrin Harkins wrote: Hi, Loading data in the parent process is a common strategy for data that you won't modify. Do you need to change this data from the child processes? If so, does it matter if the other child processes see the changes? - Perrin On Tue, Sep 16, 2014 at 10:28 AM, Nageswara rao Gurram < nageshgurra...@gmail.com> wrote: Hi, I am new to mod perl environment so this may looks naive. Recenlty I observed my apache processes are getting huge.. When I tried to dig this down I found apache parent process (rss memory , mainly shared dirty) itself is increasing with number of requests it is serving, so when everytime it is creating a new child it is sharing all its memory with childs and they are getting even more bigger and so on.. I am thinking this might be one reason. I decalred a global variable in apache startup (so it'll be shared on across all childs), this variable will be loaded with huge DB data in one of perl modules(after request comes). Will this increase shared dirty of parent ? (After child writes into it, it will no longer shared between parent and child., and parent shared dirty should get decreased .. right ?) At start parent is only 100MB and after some days it's going above 250MB and so childs are going above 400M.. Can anybody help ? Thanks, Rao.
Re: Shared Dirty memory of Apache parent process
Nageswara rao Gurram wrote: Hi, I am new to mod perl environment so this may looks naive. Recenlty I observed my apache processes are getting huge.. When I tried to dig this down I found apache parent process (rss memory , mainly shared dirty) itself is increasing with number of requests it is serving, so when everytime it is creating a new child it is sharing all its memory with childs and they are getting even more bigger and so on.. I am thinking this might be one reason. I decalred a global variable in apache startup (so it'll be shared on across all childs), this variable will be loaded with huge DB data in one of perl modules(after request comes). Will this increase shared dirty of parent ? (After child writes into it, it will no longer shared between parent and child., and parent shared dirty should get decreased .. right ?) At start parent is only 100MB and after some days it's going above 250MB and so childs are going above 400M.. Can anybody help ? Hi. First, it will probably save a lot of questioning (and time) later, if you tell us right away : - on which platform/OS this is running - what version of Apache you are using - what version of Perl - what version of mod_perl and then, what configuration of Apache you are using (pre-fork, threaded, ..?) All of that is likely to matter to the people that would try to help you.
Re: lost directory indexes
Ruben Safir wrote:
On Mon, Sep 15, 2014 at 12:24:13AM -0400, Ruben Safir wrote:
Oh yeah --
Server version: Apache/2.2.23 (Unix)
Server built: Dec 9 2012 17:26:38
Continuing on this
I'm looking at what are the allowed options
I added:
use Apache2::Access;
use Apache2::Const -compile => qw(:common);
use Apache2::Const -compile => qw(:options);
and
if($r->allow_options & Apache2::Const::OPT_INDEXES){
print STDERR "INDEXES ON\n";
}else {
print STDERR "INDEXES OFF\n";
}
if($r->allow_options & Apache2::Const::OPT_SYM_LINKS){
print STDERR "SYMLINS ON\n";
}else {
print STDERR "SYMLINKS OFF\n";
}
if($r->allow_options & Apache2::Const::OPT_EXECCGI){
print STDERR "CGI ON\n"}
else {
print STDERR "CGI OFF\n";
}
Now the error log for an index request says:
[Mon Sep 15 12:14:09 2014] [error] [client 10.0.0.57] Attempt to serve
directory: /usr/local/apache/htdocs/resources/, referer:
http://www.mrbrklyn.com/
INDEXES ON
SYMLINKS OFF
CGI OFF
It knows that INDEXES is on but it is ignoring the config files fault.
I suppose I need to identify the directory request and then decline to
respond to it.
Yes.
But I have no idea how to do this.
Have you tried
return DECLINED; # ?
See first this :
http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases
Leave that page open in a tab, to refer to it during the rest.
Then open this page in another tab, and read it, up to the RUN_ALL label.
(Really do this; it takes only a few minutes, and it will save you a lot of time in the
long run)
Then see :
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlResponseHandler
and then follow the RUN_FIRST links, to
http://perl.apache.org/docs/2.0/user/handlers/intro.html#item_RUN_FIRST
and then to
http://perl.apache.org/docs/2.0/user/handlers/intro.html#C_RUN_FIRST_
Summary :
When you install you own mod_perl response handler, it gets pushed "on top" of the Apache
default handler, so it gets called first.
If your response handler really generates a response, it should return OK, so that Apache
does not run any more response handlers after that (not even the default handler, see
below), and skips to the next phase (Logging). (Your handler can also return an error
code, and that also aborts the Response phase and goes to Logging.)
If your handler decides not to generate a response for this request (but leave it for
another handler to do that), then it should respond DECLINED, so that Apache runs the next
handler in the chain.
Eventually, if all the installed Response handlers respond DECLINED, Apache will run its
default response handler.
This default handler is always there, at the end of the Response handlers chain. It is
the one which tries to respond to the request by sending a static file (e.g. a html page
on disk) or the content of a directory.
That's what you want, here; so return DECLINED.
Re: Perl Authorization handler called before authentication handler
Lathan Bidwell wrote:
I have looked all around apache's documentation on how to upgrade from 2.2
to 2.4, but they don't include much about using PerlAddAuthzProvider or
PerlAuthenHandler.
I have this config section:
PerlAddAuthzProvider membersuser Application::User::Members->authorize24
DirectoryIndex disabled
PerlAuthenHandler Application::User::Members->authenticate24
#PerlAuthenHandler Application::User::Members::authenticate24
AuthTypeApplication::User::Members
AuthName"Members"
Require membersuser testing123
But for some reason, my authorize24 subroutine is being called before my
authenticate24 subroutine.
I have simplified those 2 subroutines down to printing debugging info to
the error log, (the authen sub sets $r->user('testing')), but I cannot
figure out why the handlers are called in the wrong order.
Not a solution, just a couple of questions, to make sure that we are seeing the issue
correctly :
1) /is/ the authenticate24 subroutine ever called ? Can you see that ?
2) what is the exact request URL used, when you encounter this issue ?
And then a tentative suggestion :
can be probably be replaced with the equivalent
which should be a little bit more efficient.
Re: mod_perl and utf8 and CGI->param
Michael Schout wrote: On 9/2/14, 4:19 PM, Randal L. Schwartz wrote: ## ensure utf8 CGI params: $CGI::PARAM_UTF8 = 1; Sorry to chime in late on this, but part of the problem with CGI.pm and UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm itself registers if its running under mod_perl. This caused major headaches for me at one time until I figured this out. You have to make sure to set $CGI::PARAM_UTF8 early, and FOR EVERY REQUEST, because if you just set it globally (e.g.: in a startup perl script), then it only works for the first request. Hi. Just an addendum to the discussion : There are really two distinct approaches to this issue, and they work at different levels : 1) is to "fix" CGI.pm so that it delivers the parameters in the way which you expect. As shown by the previous valuable and technical contributions, this generally works, but it requires a certain level of expertise; and it does not necessarily work backwards with all versions of mod_perl and CGI.pm. 2) is to take whatever CGI.pm does deliver to the calling script or module, and use a couple of tricks and some additional code in ditto script or module, to ensure that whatever CGI.pm delivers under whatever mod_perl version, the receiving script or module always knows in the end what it is dealing with. That is the method which I presented early in the discussion. As stated in that contribution, it is not necessarily the most elegant or efficient way to deal with the issue, but it has the advantage of working always, no matter which version of CGI.pm and/or mod_perl are in use. The real crux of the matter is this, in my view : as things stand today in terms of protocol and RFCs, there is no real way for CGI.pm (or any comparable framework) to be *sure* of the encoding of the data sent by a browser or another HTTP client agent. Even the RFCs do not really provide a way by which this can be enforced. (*) So if you are sure of what the client is sending, and the matter consists of *forcing* CGI.pm to always communicate POST (or GET) data as UTF-8 encoded and utf8-marked (or the opposite) to the calling script/module, then method 1 will work, and it is more elegant and probably more efficient than method 2. But if the matter consists of ensuring that the receiving code in the script/module which handles the data submitted by the HTTP client, is resilient and "does the right thing" whatever the submitted data really was, then in my opinion method 2 is better. (But that's only my opinion of the moment, and I stand ready to be corrected). (*) and if you believe this not to be true, please send me some references about it, because I am really interested. It might save me some code in all my web-facing applications.
Re: mod_perl and utf8 and CGI->param
Hi Randal.
Randal L. Schwartz wrote:
Getting really frustrated with mod_perl2's apparent inability to
probably read UTF8 input.
Here's my mod_perl2 setup:
Apache 2.2.[something]
mod_perl 2.0.7 (or nearly that)
ModPerl::Registry
Perl "script" with CGI.pm
Very early in my app:
## ensure utf8 CGI params:
$CGI::PARAM_UTF8 = 1;
binmode STDIN, ":utf8";
binmode STDOUT, ":utf8";
binmode STDERR, ":utf8";
This works fine in CGI mode: when I ask for $foo = $cgi->param('foo'),
DBI::data_string_desc($foo) shows a UTF8 string with the proper
discrepency between bytes and chars.
But when I try to run it under mod_perl, the returned string appears
to be the raw ascii bytes, and definitely not utf8. Of course, when I
store that in the database (using DBD::Pg), the "latin-1" is encoded
to "utf-8", and I get a bunch of weird chars on the output.
Has anyone managed to round-trip UTF8 from form to database and back
using a setup similar to this?
I suspect part of the problem is this in CGI.pm:
'read_from_client' => <<'END_OF_FUNC',
# Read data from a file handle
sub read_from_client {
my($self, $buff, $len, $offset) = @_;
local $^W=0;# prevent a warning
return $MOD_PERL
? $self->r->read($$buff, $len, $offset)
: read(\*STDIN, $$buff, $len, $offset);
}
END_OF_FUNC
Since I binmode STDIN, the non-$MOD_PERL works ok here. What's the
equivalent of $r->read() that marks the incoming stream as UTF8, so I
get chars instead of bytes? Or can I just read(\*STDIN) in mod_perl2
as well? (I know that was supported at one point...)
I share your frustration, as I have been dealing for a long time with multi-lingual web
applications, using perl and mod_perl.
First a very top-level comment : the basic problem here is the incompleteness of the HTTP
RFC's, and the lack of proper support of international characters sets, even still today.
When a browser is POST-ing the contents of the elements of a to a server,
there is a set of arcane rules which, in principle, determine the character set in which
this content is encoded. The problem is that these arcane rules are arcane, often
confusing, and in addition regularly flouted by different browser makes and versions (not
to even talk about umpteen non-browser proprietary HTTP client things).
For example, when a browser sends the content of a form in the "application/form-data"
"enctype", the content of each form parameter is sent as a separate section, in a form
similar to the parts in a multi-part RFC-822 email. In theory, each of these parts should
have its own "content-type" header, and if it is text, it should also contain a "charset"
attribute indicating the corresponding data's encoding.
(and if it doesn't, by virtue of the HTTP RFC's, it should be ISO-8859-1, which is still
the default HTTP character today; quite ridiculous, but so it is).
But the sad reality is that browser don't do that, and so in the practice in many cases
the server-side application is reduced to "guessing".
By experience more than by definite code knowledge, I have to suppose that this kind of
confusion sometimes also hits developers of modules such a CGI.pm and mod_perl, so that
over the years, things have tended to vary from one version to another (versions of
browsers, versions of perl, versions of mod_perl, versions of CGI.pm). Maybe also because
of all the reasons above, there is just no "right" way of handling this, so CGI.pm always
returns "bytes" (and libapreq2 may do things differwently).
In the end, rather than trying to follow the latest developments all the time and
continuously patch my programs because of all this, I have resorted to some "defensive
programming" techniques in terms of interpreting -posted data, which have been
working fine for me for the last few years. It may well be that they are a total
overkill, but in the practice they have saved me a lot of time not spent wondering why the
data in some application suddenly started to show up as "A tilde" followed by some bizarre
graphic sign (or, at the opposite, as a question mark embedded in a losange).
(Even logging this stuff and trying to figure out what is going on is a pain, because you
have to figure out first in what encoding you are logging, and second in what encoding you
are viewing your logs).
The methodology I follow is as follows :
1) all html pages of the applications should have a tag like :
2) all in the page should have the attributes
enctype="application/form-data"
accept-charset="." (the same as above)
The above 2 things do not really guarantee anything, but at least they establish some
"baseline" which helps in interpreting the rest (and slapping users when they change their
browser settings).
3) all forms contain a hidden text like
(some known sequence of
"diacritics" characters guaranteed to have a different byte length between ISO-8859-x and
UTF-8 encoding)
Th
Re: Authorization without Authentication?
Mark jensen wrote:
Thanks I guess your answer will work for me if I have only static IPs but what I have suggested is an example, my DB or DNS zone is changing dynamically, can mod_perl deal with them as a DB?
sub Handler {
my $r = shift;
my $c = $r->connection;
my $user = $c->remote_ip;
$r->user($user);
return OK;
}
References :
https://perl.apache.org/docs/2.0/api/Apache2/Connection.html
https://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html
Re: Authorization without Authentication?
Mark jensen wrote: I have seen this link: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthzHandler and as it said: This phase requires a successful authentication from the previous phase, because a username is needed in order to decide whether a user is authorized to access the requested resource. but what if I don't want to authenticate users (BECAUSE I have already authenticate them using freeRADIUS and IEE802.1x) , I want only to authorize them, you would ask me how can we get the username. I have usernames with there IPs in mysql DB like this: userIP Mark 192.168.1.10 Mike192.168.1.11 and I have them too in the DNS: in its revers zone (1.168.192.in-addr.arpa): $TTL 60 ; 1 minute 10PTR Mark 11PTR Mike How can I let module_perl make use of mysql DB or DNS zone to authorize my users using PerlAuthzHandler ? You could create and configure a "dummy" PerlAuthHandler, which sets $r->user to whatever value you consider as the "authenticated user-id" (such as the above IP) and returns OK. Then in PerlAuthzHandler, you pick up $r->user and use it for your authorization. This way, if in the future you change your mind about Radius or whatever, you only have to change the PerlAuthHandler, and everything will continue to work smoothly.
Re: bug in trunk in Apache::Reload test
There is also something to be said for writing clear and obvious code, even if it does
cost a couple of CPU cycles of which there are about 2.5 billion available every second.
I prefer this version :
my $args = $r->args;
if (defined($args) && ($args eq 'last')) {
...
}
unless $args is used exclusively inside the if {} block (*).
Clear, no side-effects, no hidden meaning behind the "if ($args)", no double dereferencing
overhead - assuming perl doesn't optimise this itself - , no worries about operator
precedence etc.
Syntactic sugar and perl virtuosity are nice if they are for one's self-satisfaction,
hubris and laziness, but if some junior has to handle this code after you lose interest,
it's better to be plain and obvious.
(*) in which case I might just about forgive you for writing
if (defined(my $args = $r->args) && ($args eq 'last')) {
, although that would probably force the junior to consult the (otherwise excellent and
humorous) perl documentation to verify the scope of $args.
Mark Hedges wrote:
Nope Joshua you're right, I missed that.
defined() is faster than the logical check because the logical check checks
defined, then checks if empty string, then checks if numerically 0, except if
it is 0E0 (zero but true). One operation versus the same operation plus three
more; the one by itself is certainly less computation.
However I'm not sure about the last one. That is a cool idea. We'd have to
benchmark it. :-)
Also is '&&' faster than 'and'?
Mark
From: sergiy.borod...@gmail.com [mailto:sergiy.borod...@gmail.com] On Behalf Of
Sergiy Borodych
Sent: Thursday, June 26, 2014 2:14 AM
To: Joshua Narins
Cc: Mark Hedges; modperl@perl.apache.org
Subject: Re: bug in trunk in Apache::Reload test
Hello,
another question:
why not just
my $args = $r->args;
if ( $args and $args eq 'last' ) {
(without defined)
or even
if ( my $args = $r->args and $args eq 'last' ) {
:)
2014-06-26 10:52 GMT+03:00 Joshua Narins :
On Mon, Jun 23, 2014 at 06:21:37PM +, Mark Hedges wrote:
Perl 5.20.0, Apache 2.2.27, APR 1.5.1, APR-util 1.5.3, mod_perl trunk.
2014-06-23 11:16:32 Mon $ svn diff t/lib/Apache2/TestReload.pm
Index: t/lib/Apache2/TestReload.pm
===
--- t/lib/Apache2/TestReload.pm (revision 1604706)
+++ t/lib/Apache2/TestReload.pm (working copy)
@@ -15,7 +15,8 @@
sub handler {
my $r = shift;
$pass++;
-if ($r->args eq 'last') {
+my $args = $r->args;
+if (defined $args && $r->args eq 'last') {
Apache2::Reload->unregister_module($package);
ModPerl::Util::unload_package($package);
$pass = 0;
Why not just
my $args = $r->args;
if (defined $args and $args eq 'last') {
I guess repeat calls to $r->args have virtually no cost?
Re: Problem with Apache2::AuthCookie and Apache 2.4: "failed to resolve handler"
Brian Candler wrote: OK I have it. The Debian-supplied version of Apache2::AuthCookie *does* have the patches from the httpd24 branch of authcookie, and the documentation for how to use it is in /usr/share/doc/libapache2-authcookie-perl/README.apache-2.4 Very useful information, thanks for sharing it. My testsite can be made to work like this: --- testsite.conf.orig2014-06-25 14:16:51.365038932 +0100 +++ testsite.conf2014-06-25 14:20:29.974486565 +0100 @@ -3,6 +3,7 @@ PerlModule Example::AuthHandler PerlSetVar TestAuthPath /testsite PerlSetVar TestAuthLoginScript /testsite/login.html +PerlAddAuthzProvider user Example::AuthHandler->authz_handler ### To recognize logged-in users even outside of protected area: @@ -16,7 +17,6 @@ AuthType Example::AuthHandler AuthName TestAuth PerlAuthenHandler Example::AuthHandler->authenticate - PerlAuthzHandler Example::AuthHandler->authorize Require valid-user Unfortunately I'm now battling with Apache2::SiteControl, but that's a different ball game. Sorry for the noise, but hopefully somebody finds this useful. Extremely. I created a very specifc Auth/Authz module for Apache2.0/2.2, on the base of copying Apache2::AuthCookie instead of subclassing it (bad me, but the changes were so extensive that I was kinda forced to). Your commented struggles - and their eventual solution - will definetely help me when the time comes to update this for 2.4. Thanks for sharing. André.
Re: what is "world domination series"?
I may be thick, or not in the loop, but I didn't get this. Care to provide a hint ? Mark Hedges wrote: *lol* ... `force install App::Ack` ... silly people :-) From: Mark Hedges Sent: Sunday, June 22, 2014 11:10 PM To: modperl@perl.apache.org Cc: Mark Hedges Subject: what is "world domination series"? Apache/2.2.27 (Unix) world domination series/2.0 mod_perl/2.0.8 Perl/v5.20.0 Server at localhost Port 8529 ... rather ominous ... Thanks. Mark
Re: Something wrong with CPAN ?
I Close wrote: On 09/06/14 12:23, André Warnier wrote: Hi guys. Is it only me, or does the search box in www.cpan.org not work anymore ? 503 Service Unavailable No server is available to handle this request. (been like that for a couple of days now) I have noticed its seemingly been intermittent for the past few weeks, often its down with a 503 during the small hours in the GMT time zone. It is down right now : 10:17 PM Monday, June 9, 2014 (GMT) Time in Greenwich Mean Time Don't know if this qualifies as a "small hour". But then, your own email to the list comes in as dated : 04.06.2014 22:38 which on the face of it is 5 days ago, long before I sent the initial email of this thread; which throws at least some doubt as to the accuracy of your comment above. ;-)
Something wrong with CPAN ?
Hi guys. Is it only me, or does the search box in www.cpan.org not work anymore ? 503 Service Unavailable No server is available to handle this request. (been like that for a couple of days now) If it is not me alone, and if someone here knows where to send a message about this, could you advise ? Thanks André
Re: API Docs
Worik Stanton wrote: On 16/05/14 21:09, André Warnier wrote: Maybe you should start here : https://perl.apache.org/docs/2.0/user/handlers/intro.html#What_are_Handlers_ Thank you. That is very useful Welcome. One thing which you cannot complain about apparently, is the number of answers you're getting. mod_perl advocacy seems alive and well. Don't hesitate to ask if you have further questions. Let me also point you to a couple of other sources of information which I have found useful in learning Apache and mod_perl (and later ever again as a reference): http://www.modperlcookbook.org/chapters/part3.pdf (the schema on page 378) in conjunction with : https://perl.apache.org/docs/2.0/user/handlers/intro.html#mod_perl_Handlers_Categories The point is : Apache httpd does not need to be presented anymore : it is the most widely used webserver on the WWW, and it has a very stable, very optimised code base, and a plethora of capabilities. Apache httpd handles each request in a series of well-defined consecutive steps, each step doing something specific in terms of interpreting the request, possibly transforming it, checking access permissions, then executing the request in order to generate a certain content, then cleaning up and logging. Each of these Apache steps offers "hooks", into which you can attach your own code, to have it executed by Apache, to modify or replace what the native Apache code would normally do at that stage. mod_perl allows you to attach your own perl code to any of these hooks, in a simple and dynamic way, so that you can - if you wish - take almost complete control of what Apache does with any given request. And because this is perl, you can try out something in a matter of minutes, using the vast CPAN library of perl modules to help you do complex things in a simple way. And you can leave all the sordid details that you do not want to deal with, to the efficient and hyper-reliable Apache httpd code base. That's the real beauty of it. In addition, because mod_perl embeds a perl interpreter and run-time into Apache itself, and it pre-compiles everything that you add, it is also fast. The only drawback is memory usage. But then, if you compare this to java-based webservers, there is still a comfortable margin.
Re: API Docs
Worik Stanton wrote:
I am still trying to fathom the API.
I have struck a snag with the documentation.
https://perl.apache.org/docs/2.0/api/Apache2/Connection.html#Synopsis
says
use Apache2::Connection ();
use Apache2::RequestRec ();
my $c = $r->connection;
What is $r?
I am missing something obvious, what is the context here I do not get?
Hi.
Maybe you should start here :
https://perl.apache.org/docs/2.0/user/handlers/intro.html#What_are_Handlers_
$r is the "current request object". How you obtain it varies a bit depending on where you
are (in a mod_perl handler, in a cgi-bin script etc..).
Usually, you'll be in some kind of handler() sub, and the usual idiom then is
just
sub handler {
my $r = shift;
..
}
as the request object is the first and usually the only parameter passed in
such a sub/method.
It is also usually the starting point for everything else in mod_perl.
If you are a real beginner, a recommendation : persist, you'll soon get the hang of it,
and it's worth the effort. Perl is fun; Apache + mod_perl is *a lot* of fun, and
incredibly powerful.
Re: Apache 2.2 and Authorization Providers under mod_perl
Skylos wrote:
Trying to migrate an application to mod_perl under apache 2.2 but my custom
auth handlers are blowing up on failure to understand '$r->requires'
method. The best I can make of it is that apache 2.2 revamped the auth
system requiring the definition of providers (like 'group' allowing the
'Require group ' directive in the config file.
It seems then that I need to define my own authentication provider...
perl-group? mycustomauth-group, so i can say
Require mycustomauthgroup admin
Thus get the proper ->requires information during the authorization phase
for checking?
David
PS: I apologize for not being able to derive this answer from my search and
browsing of the mailing list archives if the answer is in there. I found
some that seemed exactly related to this issue under topic mp 2.0.3 make
test fails against httpd trunk: Has authorisation changed since httpd 2.2 ? but
was unable to find anything about actually defining these authorization
providers...
Hi.
This is not really an answer to your question, but I felt it might help anyway, only to
allow you to sleep better..
I also wrote my own authentication framework for Apache/mod_perl (using
Apache2::AuthCookie as base, many thanks to the author and maintainers), and I do not
recall having had to do any major surgery to it between 2.0 and 2.2 (2.4 may be another
matter though).
In any case, I am sure that the "group" aspect is not needed, because I don't do that at
all and my stuff still works fine.
So, while I'm not the ultimate expert, I would think that whatever you may have to do is
probably less major than what you are hinting at above.
HTH.
P.S. check the code for Apache2::AuthCookie for many tips (sub authorize{}).
I am using its get_statisfy() and satisfy_is_valid() subs.
And I only use "require user xxx" or "require valid user" in the Apache config.
Re: PATCH: add -DAPACHE24 support to Apache::Test - necessary for Auth with Apache 2.4
Not an answer to your question, but many thanks for that module, for keeping it up-to-date, and for pointing out the differences in Apache 2.4. I used Apache::Cookie as a base to create my own module which does just about every authentication under the sun (for a particular back-end), and it was very valuable. It looks like I'll have my work cut out to adapt to Apache 2.4 though. Incidentally, where can I find a description of the new Apache 2.4 API ? Michael Schout wrote: Hi. I have submitted this issue a while back to rt.cpan.org, but I have not gotten any response. I am the maintainer of Apache::AuthCookie. As most of us probably already know, Apache 2.4 has a very different authentication API from previous Apache versions. As a result, in order to release a version of Apache::AuthCookie that passes tests on Apache 2.4 and previous versions, it is necessary to have conditional config sections that are only enabled for Apache 2.4 or later. Currently Apache::Test defines APACHE2 if running under apache 2.0 or later. The attached patch also defines APACHE24 if running under apache 2 with a minor version >= 4. I shipped a patch for AuthCookie to the debian folks that works under Apache 2.4, but I also need this patch in Apache::Test in order to make it so that the test suite will work on all Apache versions (2.4 as well as 2.2 and earlier) Example in AuthCookie t/conf/extra.conf.in: # Apache 2.4+ Auth API PerlAddAuthzProvider user My::Auth->authz ... ... # Pre Apache 2.4 Auth API. PerlAuthzHandler Hopefully this makes it clear why this is needed, and why I'd like to see this in Apache::Test before mod_perl for apache 2.4 is finalized. Regards, Michael Schout
Re: Initial setup problems with mod_perl2 - unable to locate modules
Da Rock wrote: ... > SetHandler modperl PerlResponseHandler Mod_home::Mod These 2 lines above should be enough. Again as I thought. But if I may ask (for later configuration), how is access controlled? Using auth or access in the perl module rather than server acl's? What I was showing off (granted, not entirely on-topic), with PerlAuthHandler and PerlAuthzHandler and friends, is one *essential* capability of mod_perl, which is often missed/ignored (at least by beginners) : the fact that mod_perl allows one to intervene with appropriate mod_perl modules and call-backs, at just about every stage of Apache's HTTP request processing (and even outside of that). That includes the Access-control, Authentication and Authorization stages. So you can entirely substitute Apache httpd's AAA code by your own mod_perl code, and design any AAA mechanism you wish, easily (as compared to writing your own Apache add-on modules in C e.g.). (Or interleave your own code with Apache httpd's, in just about any way you can imagine). So if you want or need for example to create a new HTTP authentication method which depends on the phase of the Moon (instead of HTTP Basic or Digest or Windows Domain or LDAP or database-based or server-ACL based), you can do so, very easily. Mod_perl is much more than running perl cgi-bin scripts on steroids, or writing your own response handlers. It allows you to take Apache httpd as a base (and all the general HTTP plumbing it handles for you reliably and fast), add mod_perl and perl, and add the CPAN library, and you get an incredibly powerful and flexible mix. That's the real beauty of it, which to my knowledge is not available with any other Apache plugged-in language or module. So please, do not get discouraged by a little bit of configuration trouble, or by an occasional not entirely accurate error log message, because you would be missing a lot of power and fun. Also, the on-line mod_perl documentation (with warts and all), is still in my view one of the best sources in terms of understanding how Apache httpd works, and even about HTTP in general.
Re: Initial setup problems with mod_perl2 - unable to locate modules
André Warnier wrote:
Hi.
Da Rock wrote:
I know this may seem straight forward and a RTFM response may be in
order, but I have been trying to crack this for some days now
(following attempts on and off, too, mind) and nothing I can google
seems to point to an accurate answer on what the problem is here.
I'm running FreeBSD 9.x with Apache22, and installed mod_perl2 to try
to switch away from php based development based on current requirements.
I have tried using a startup.pl, but I would like to just use
PerlSwitches -I instead (which from what I read is possible);
regardless the issue remains the same.
I get a 500 response in the browser, and the logs have these errors:
"failed to resolve handler `Mod_home::Mod': Can't locate
Mod_home/Mod.pm in @INC"
it should normally also show you what it finds in @INC. What does it say ?
and simply "failed to resolve handler" in the main server log.
My config looks like this:
:>
ServerName
ServerAlias
ServerAdmin
ErrorLog "/var/log/apache/-error.log"
CustomLog "/var/log/apache/-access.log" common
PerlOptions +Parent
PerlSwitches -I/usr/local/www//lib
Can you show us the contents of that directory ?
PerlInitHandler Apache2::Reload
PerlModule Mod_home::Mod
I don't think that you need the above.
>
SetHandler modperl
PerlResponseHandler Mod_home::Mod
These 2 lines above should be enough.
Order allow,deny
Allow from all
I also have PerlModule Apache2::Reload in the httpd.conf.
Just to reiterate - I have tried this both as vhosting and as single
server setup, and I cannot seem to resolve the same issue every single
time.
Can someone please give the magical incantation to make this thing
work? :-) or at least point me in the right direction? I'm really
starting to lose patience with this thing, and I now have a deadline
to sort this out which is fast approaching.
Yes, but that's not the fault of anyone who is trying to help you here.
So be patient.
I am doing things similar to what you are intenting to do, on many
servers with VirtualHosts, and it works flawlessly. So it /is/ a
configuration matter, not something wrong with Apache/mod_perl in the
first place.
The thing is, we don't see your system, so we depend on the accurate and
complete information that you are providing us with.
When you (re-)start your Apache server, it prints a statup line in the
logs (error log).
Can you show it here ?
example :
[Sun Feb 09 06:25:45 2014] [notice] Apache/2.2.16 (Debian) mod_jk/1.2.30
mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
and then give us the *full* message that appears in the log when it
doesn't find your module.
Example of a configuration which works (Linux Debian, Apache 2.2, mod_perl 2.0)
:
1) Apache config, "main" server :
...
LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so
...
PerlSetEnv TMPDIR "/tmp"
PerlOptions +GlobalRequest
PerlRequire "/etc/apache2/modperl2_startup.pl"
SetEnv PERL5LIB "/somepath/lib" # one way of setting the modules lookup path
...
and in modperl2_startup.pl :
#!/usr/bin/perl
# modperl2_startup.pl
# Apache2 / mod_perl 2 startup script
use Bundle::Apache2 ();
use lib "/somepath/lib"; # another way of setting the modules lookup path
# preload often-used modules, YMMV
use ModPerl::Util ();
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::Filter ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use Apache2::Const -compile => qw(:common :log REDIRECT);
use APR::Const -compile => ':common';
use APR::Table ();
use ModPerl::Registry ();
use CGI ();
CGI->compile(':all');
1;
2) in VHost config :
...
PerlSetVar Var1 "Value1"
PerlSetVar Var2 "Value2"
/docs>
..
AuthType AUTH::StarLogCookie
AuthName XXXtop
PerlAuthenhandler AUTH::StarLogCookie->authenticate
PerlAuthzHandler AUTH::StarLogCookie->authorize
require valid-user
..
That was just to show off that you can do all kinds of things with mod_perl.
But here is something closer to your wishes :
SetHandler modperl
PerlSetVar Var1 "Valuex" # overrides the general one above
PerlSetVar Var3 "Value3"
PerlResponseHandler My::Module # or My::Module->handler, it
depends
and in /something/lib/, there is :
- My
|- Module.pm
and Module.pm has a
sub handler() {
}
So you do not need to specifically "load" My::Module in advance.
The PerlResponseHandler should be enough.
Re: Initial setup problems with mod_perl2 - unable to locate modules
Hi. Da Rock wrote: I know this may seem straight forward and a RTFM response may be in order, but I have been trying to crack this for some days now (following attempts on and off, too, mind) and nothing I can google seems to point to an accurate answer on what the problem is here. I'm running FreeBSD 9.x with Apache22, and installed mod_perl2 to try to switch away from php based development based on current requirements. I have tried using a startup.pl, but I would like to just use PerlSwitches -I instead (which from what I read is possible); regardless the issue remains the same. I get a 500 response in the browser, and the logs have these errors: "failed to resolve handler `Mod_home::Mod': Can't locate Mod_home/Mod.pm in @INC" it should normally also show you what it finds in @INC. What does it say ? and simply "failed to resolve handler" in the main server log. My config looks like this: :> ServerName ServerAlias ServerAdmin ErrorLog "/var/log/apache/-error.log" CustomLog "/var/log/apache/-access.log" common PerlOptions +Parent PerlSwitches -I/usr/local/www//lib Can you show us the contents of that directory ? PerlInitHandler Apache2::Reload PerlModule Mod_home::Mod I don't think that you need the above. > SetHandler modperl PerlResponseHandler Mod_home::Mod These 2 lines above should be enough. Order allow,deny Allow from all I also have PerlModule Apache2::Reload in the httpd.conf. Just to reiterate - I have tried this both as vhosting and as single server setup, and I cannot seem to resolve the same issue every single time. Can someone please give the magical incantation to make this thing work? :-) or at least point me in the right direction? I'm really starting to lose patience with this thing, and I now have a deadline to sort this out which is fast approaching. Yes, but that's not the fault of anyone who is trying to help you here. So be patient. I am doing things similar to what you are intenting to do, on many servers with VirtualHosts, and it works flawlessly. So it /is/ a configuration matter, not something wrong with Apache/mod_perl in the first place. The thing is, we don't see your system, so we depend on the accurate and complete information that you are providing us with. When you (re-)start your Apache server, it prints a statup line in the logs (error log). Can you show it here ? example : [Sun Feb 09 06:25:45 2014] [notice] Apache/2.2.16 (Debian) mod_jk/1.2.30 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations and then give us the *full* message that appears in the log when it doesn't find your module.
Re: Problem with Apache2::Connection::remote_ip
Steve Baldwin wrote: Hi, Not sure what I'm doing wrong here. I'm just trying to get the client ip address in a PerlResponseHandler as follows: : use Apache2::Connection; : my $remote_ip = $r->connection->remote_ip(); : I get a runtime error as follows: [Sun Feb 09 16:44:22.499681 2014] [perl:error] [pid 3632] [client 192.168.1.105:52533] Can't locate object method "remote_ip" via package "Apache2::Connection" at /usr/local/lib/site_perl/Storm/Dev/Handler.pm Here are the various versions (OS = Ubuntu 13.10) : [Sun Feb 09 16:44:01.267265 2014] [mpm_prefork:notice] [pid 3625] AH00163: Apache/2.4.6 (Ubuntu) PHP/5.5.3-1ubuntu2.1 mod_perl/2.0.8 Perl/v5.14.2 configured -- resuming normal operations This is not going to help you much, but I can at least confirm that I do exactly the same as you : my $remote_ip = $r->connection->remote_ip || ''; in one of my mod_perl modules, and that it works several hundred times a day without error, under the following versions : [Sun Feb 02 06:25:07 2014] [notice] Apache/2.2.9 (Debian) DAV/2 mod_jk/1.2.26 mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Sun Feb 09 06:26:34 2014] [notice] Apache/2.2.16 (Debian) DAV/2 mod_jk/1.2.30 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations [Sun Feb 09 06:26:51 2014] [notice] Apache/2.2.22 (Debian) mod_apreq2-20090110/2.8.0 mod_perl/2.0.7 Perl/v5.14.2 configured -- resuming normal operations
Re: New Windows mod_perl binaries available for Perl 5.18.1
Steve Hay wrote: For those who are interested, I have uploaded binary 64-bit builds of mod_perl-2.0.8 and libapreq2-2.13 components compatible with Apache Lounge 2.2.25 Build 29 June 2013 (win64) and each of: * ActivePerl 5.18.1 Build 1800 (x64) * Strawberry Perl 5.18.1 Build 1 (64bit) You can download them from http://people.apache.org/~stevehay/ Please let me know if you have any problems. Regards, Steve PS. I have not made 32-bit builds this time because ActivePerl and Strawberry Perl 5.18.1 are both now built with 64-bit integers, which is binary-incompatible with the 32-bit integers in Apache Lounge's Win32 build. Thank you very much. Really helps. André Warnier Mira Consulting GmbH
Re: Web Server Architecture
Joseph D Carroll Jr wrote: I am new to httpd (or any web server for that matter) and I am trying to play around with some things using Amazon Web Services. So as much as I may be looking for an answer, I am more interested in where I can figure all of this out. I am setting up a simple web site (just as a demo for myself) not unlike the apache.org site. A relatively simple site with a forum (FUDforum), bugzilla, and a couple of other simple services. I have been able to figure out enough where I am able serve a simple html website; however, I am now working on implementing Bugzilla and I have run into an issue. I would like to host bugzilla on what I will call "Box B" and I have httpd currently running on what I'll call "Box A" (because I feel like that is more secure/professional ?). I am unclear on how to serve content from Box B through Box A, would someone be able to provide a little more clarity? If I had to guess: - Box B would be listed as a "virtual host" under Box A - Box B would be running a separate instance of httpd and wouldn't know/care if requests were coming through Box A or directly from the web Other questions: - I have not defined any kind of domain for these (AWS) instances, will that be a problem for now? Hi. I think that your questions have very little to do with mod_perl, which is the focus of this help list. You are probably better off asking this on the general Apache httpd forum. As a purely personal note : if you are really as new as inexperienced as you claim to be above, it looks to me as if what you are trying to set up is already fairly complex for a first exercise. My suggestion would be to first stick to one webserver on one box, hosting one application, and when you really understand how it all works, then start to add more applications and/or move pieces around. It will also be easier for you to find help at each stage, rather than asking for such general kind of help which would take days of someone's time.
Re: [URGENT] Do not post below post on Internet
Hi. You do realise that the more attention you draw to this, the more likely someone is to really go search through the dozens of archived versions of these messages, to find what you are so worried about ? Do as someone wrote earlier : change that information on your servers, now. There is no alternative. By delaying and writing more about it, you only make it worse. It is *impossible* for anyone to go now and delete all the copies of these posts. If you have been reading any newspapers in the last couple of months, you'll understand why. jitendra.s...@accenture.com wrote: Hi Staveren, Please do the needful to delete the post, its very urgent. Met vriendelijke groet / With kind regards, Jitendra Soni -Original Message- From: Ben van Staveren [mailto:benvanstave...@gmail.com] Sent: Tuesday, August 20, 2013 3:52 PM To: modperl@perl.apache.org Subject: Re: [URGENT] Do not post below post on Internet On 08/20/2013 01:59 PM, jitendra.s...@accenture.com wrote: Dear members, Request you to not to post below mail discussion with subject line to Internet due to security reasons: It's uh, already archived in more places than I care to mention... This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com
Re: Detection "connection reset by peer" in mod_perl before send a response
Lucas wrote: Dear all. I need to detect that user pressed escape, apache receives it like "connection reset by peer" (I saw it with truss, freebsd strace), before my script will send a response to client. I can explain: my script works some time (about 2-3 sec), it gathers some data. Within this period it is possible that user decide to press escape or even to close the page or browser. I need to detect it and clean some temporary files, what is normally happen by additional request from script on the page. I need your advice how to do it. First, you need to think about the whole setup between your script and the user's browser, like this (1 line) : script <-> perl <-> Apache <-> network <-> firewall/proxy <-> internet <-> internet <-> <-> firewall/proxy <-> user browser Any of the "things" between your script and the user's browser has buffers, and may be setting up separate TCP connections in-between. It's not like your script is directly connected to the user's browser in any way. In other words, if the user "walks away" from your page at any time, there is no guarantee that your Apache server (and even less your script) would get any kind of signal back, indicating that the user has done that. The only time when your script can know that the user "has gone away", is if your script tries to write something to the connection at the end of which is the user's browser, and it gets back an error from Apache/perl saying that there is no connection anymore, and that the write could not happen. And even Apache/perl may not necessarily know that the user has gone away, because they may have finished writing to the network, and the response may be somewhere still in a buffer somewhere along the way. So basically, you need to revise the logic of your application so that it does not depend on any kind of signal coming back from the browser, because there is no guarantee that you will ever get such a signal back. That can be complicated, but that is simply how HTTP works, and there is nothing that you can do to change that. If you cannot/do not want to do this, then you need to think about another way than HTTP to connect your application with the user's browser, such as "websockets" e.g.
Re: mod_perl and Transfer-Encoding: chunked
Bill Moseley wrote:
André, thanks for the response:
On Thu, Jul 4, 2013 at 4:06 AM, André Warnier wrote:
Bill Moseley wrote:
First, if $r->read reads unchunked data then why is there a
Transfer-Encoding header saying that the content is chunked? Shouldn't
that header be removed?
Looking at the RFC again the answer appears to be yes. Look at the last
line in this decoding example in
http://tools.ietf.org/html/rfc2616#section-19.4.6
A process for decoding the "chunked" transfer-coding (section 3.6
<http://tools.ietf.org/html/rfc2616#section-3.6>)
can be represented in pseudo-code as:
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
Apache/mod_perl is doing the first part but not updating the headers.
There's more on Content-Length and Transfer-Encoding here:
http://tools.ietf.org/html/rfc2616#section-4.4
How does one know if the content is chunked or not, otherwise?
The real question is : does one need to know ?
Perhaps. That's an interesting question. Applications probably don't
need to care. They should receive the body -- so for mod_perl that means
reading data using $r->read until there's no more to read and then the app
should never need to look at the Transfer-Encoding header -- or
Content-Length header for that matter by that reasoning.
It's a bit less clear if you think about Plack. It sits between web
servers and applications. What should, say, a Plack Middleware component
see in the body if the headers say Trasnfer-Encoding: chunked? The
decoding probably should happen in the
server<https://github.com/plack/Plack/issues/404#issuecomment-18124054>,
but the headers would need to indicate that by removing the
Transfer-Encoding header and adding in the Content-Length.
Perhaps I'm approaching this incorrectly, but this is all a bit untidy.
I'm using Catalyst and Catalyst needs a Content-Length.
I would posit then that Catalyst is wrong (or not compatible with HTTP 1.1
in that respect).
But, Catalyst is a web application (framework) and from your point above it
should not care about the encoding and just read the input stream by
calling ->read(). Really, if you think about Plack, Catalyst should never
make exceptions based on $ENV{MOD_PERL}.
So, the separation of concerns between the web server and the app is not
very clean.
So, I have a Plack
Middleware component that creates a temporary file writing the buffer from
$r->read( my $buffer, 64 * 1024 ) until that returns zero bytes. I pass
this file handle onto Catalyst.
So what you wrote then is a patch to Catalyst.
No, the Middleware component should be usable for any application. And
likewise, for any web server. That's the point of Plack.
Obviously, there's differences between web servers and maybe we need code
that understans when running under mod_perl that the Transfer-Encoding:
chunked header should be ignored, but if that code must live in Catalyst
then that's really breaking the separation that Plack provides.
I think the sane thing here is if Apache/mod_perl didn't provide a header
saying the body is chunked, when it isn't. Otherwise, code (Plack, web
apps) that receive a set of headers and a handle to read from don't really
have any choice but to believe what it is told.
I can see your point, but to me it depends at which level this add-on code
"lives".
I do not know Plack or Catalyst, and do not know at which level each of them is supposed
to "live".
But to me, if the code lives at the "web-app" level, at that point it should just consider
the request body as one piece or stream, without intervening "chunk headers".
(and it should treat the Content-transfer-encoding header as informational only, maybe to
know that it should not expect a Content-length header, and that it can only know the body
length by reading it).
It is different in the case of a mod_perl "connection filter". That one really sees the
stream of bytes coming from the browser, request line, headers, body chunked or not, etc..
(And it should see several requests pipelined on the same connection, one after the other,
as one stream of bytes, without any particular break between them other that what it can
figure out itself.)
But even a "request filter" (which comes before a web-app) should see the request body as
already "de-chunked&q
Re: mod_perl and Transfer-Encoding: chunked
Not disregarding the other answers to your questions, but I believe that maybe one aspect has been neglected here. Bill Moseley wrote: For requests that are chunked (Transfer-Encoding: chunked and no Content-Length header) calling $r->read returns *unchunked* data from the socket. That's indeed handy. Is that mod_perl doing that un-chunking or is it Apache? But, it leads to some questions. First, if $r->read reads unchunked data then why is there a Transfer-Encoding header saying that the content is chunked? Shouldn't that header be removed? How does one know if the content is chunked or not, otherwise? The real question is : does one need to know ? The transfer-coding is something that even an intermediate HTTP proxy may be allowed to change, for reasons to do with transport of the request along a section of the network path. It should be entirely transparent to the application receiving the data. Second, if there's no Content-Length header then how does one know how much data to read using $r->read? One answer is until $r->read returns zero bytes, of course. Indeed. That means that the end of *this* request body has been encountered. But, is that guaranteed to always be the case, even for, say, pipelined requests? It should be, because $r concerns the present request being processed. If there is another request pipelined onto that same connection, it is a separate request and a different $r. My guess is yes because whatever is de-chunking the request knows to stop after reading the last chunk, trailer and empty line. Can anyone elaborate on how Apache/mod_perl is doing this? I can't really, but it should be done by something at some fairly low level. It should be the *first* thing which happens to the request body, before any request-level body access is allowed. (Similarly, at the response level, "chunking" a response body should be the last thing happening before the request is put on the wire out.) Perhaps I'm approaching this incorrectly, but this is all a bit untidy. I'm using Catalyst and Catalyst needs a Content-Length. I would posit then that Catalyst is wrong (or not compatible with HTTP 1.1 in that respect). So, I have a Plack Middleware component that creates a temporary file writing the buffer from $r->read( my $buffer, 64 * 1024 ) until that returns zero bytes. I pass this file handle onto Catalyst. So what you wrote then is a patch to Catalyst. Then, for some content-types, Catalyst (via HTTP::Body) writes the body to * another* temp file.I don't know how Apache/mod_perl does its de-chunking, but I can call $r->read with a huge buffer length and Apache returns that. So, maybe Apache is buffering to disk, too. In other words, for each tiny chunked JSON POST or PUT I'm creating two (or three?) temp files which doesn't seem ideal. I realise that my comments above don't really help you in your specific predicament, but I just felt that it was good to put things back in their place, particularly that at the $r (request) level, you should not have to know if the request came in chunked or not. And that if a client sends a request with a chunked body, you are not necessarily gettting it so on the server on the which application runs. And vice-versa.
Problem installing SOAP::SOM, in dependency SOAP::Lite
Hi. I don't really know if SOAP::Lite is supported or not ;-), but I saw PHRED lurking around here, so I'll try my luck. While trying to find my way around to interface with a Sharepoint web service, I encounter the following issue (visible at end if you want to skip to the flesh) : Platform : Windows XP SP3 Perl (Strawberry) : C:\WINDOWS>perl -V Summary of my perl5 (revision 5 version 16 subversion 3) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='Win32 strawberry-perl 5.16.3.1 #1 Tue Mar 12 13:55:20 2013 i386' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict -aliasing -mms-bitfields', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.6.3', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags ='-s -L"C:\sperl\perl\lib\CORE" -L"C:\sperl\c\lib"' libpth=C:\sperl\c\lib C:\sperl\c\i686-w64-mingw32\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lneta pi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl516.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"C:\sperl\perl\lib\CORE" -L"C:\sperl\c\lib"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF Built under MSWin32 Compiled at Mar 12 2013 14:01:07 @INC: C:/sperl/perl/site/lib C:/sperl/perl/vendor/lib C:/sperl/perl/lib . Problem: C:\WINDOWS>cpan SOAP::SOM CPAN: CPAN::SQLite loaded ok (v0.202) Database was generated on Sat, 01 Jun 2013 14:34:32 GMT Running install for module 'SOAP::SOM' Running make for P/PH/PHRED/SOAP-Lite-0.716.tar.gz CPAN: LWP::UserAgent loaded ok (v6.04) CPAN: Time::HiRes loaded ok (v1.9725) Fetching with LWP: http://cpan.strawberryperl.com/authors/id/P/PH/PHRED/SOAP-Lite-0.716.tar.gz CPAN: YAML::XS loaded ok (v0.39) CPAN: Digest::SHA loaded ok (v5.84) Fetching with LWP: http://cpan.strawberryperl.com/authors/id/P/PH/PHRED/CHECKSUMS CPAN: Compress::Zlib loaded ok (v2.06) Checksum for C:\sperl\cpan\sources\authors\id\P\PH\PHRED\SOAP-Lite-0.716.tar.gz ok CPAN: Archive::Tar loaded ok (v1.90) CPAN: File::Temp loaded ok (v0.22) CPAN: Parse::CPAN::Meta loaded ok (v1.4404) CPAN: CPAN::Meta loaded ok (v2.120921) CPAN: Module::CoreList loaded ok (v2.83) CPAN.pm: Building P/PH/PHRED/SOAP-Lite-0.716.tar.gz We are about to install SOAP::Lite and for your convenience will provide you with list of modules and prerequisites, so you'll be able to choose only modules you need for your configuration. XMLRPC::Lite, UDDI::Lite, and XML::Parser::Lite are included by default. Installed transports can be used for both SOAP::Lite and XMLRPC::Lite. Press to see the detailed list. Feature PrerequisitesInstall? - Core Package [*] Scalar::Util always [*] URI [*] constant [*] Test::More [*] MIME::Base64 [*] Class::Inspector [*] XML::Parser (v2.23) [*] Task::Weaken Client HTTP support [*] LWP::UserAgent always Client HTTPS support [*] Crypt::SSLeay[ yes ] Client SMTP/sendmail support [*] MIME::Lite [ yes ] Client FTP support[ ] SOAP::Transport::FTP (v0.711) [ no ] Client TCP support[ ] SOAP::Transp
Re: [OT] Apache::DBI
lemented by the maintainers, but patches for those features are usually readily accepted. On Fri, May 31, 2013 at 10:30 AM, Jim Schueler wrote: No apology please. In terms of trying to qualify any of this, a larger statistical pool is better. And I am no authority. My perceptions are largely based on forum postings which causes an inherent bias. I'd love to see this conversation continue, especially if participants included those who commit significant resources to their technology decisions. In other words, people who hire and pay Perl programmers. They're likely to be as skeptical as I am. I've never been a cheerleader. In their absence, I'd note that your post has an interesting ambiguity: Is the number of unsupported modules 2.5% or 25%? (For more rhetorical nit-picking, you probably don't use the ones that don't work :) Also, the significant question seems to be whether Apache::DBI is supported or not. From Mr. Zheng's point-of-view (in this case, the one that matters) the number might be much higher. -Jim On Fri, 31 May 2013, André Warnier wrote: Just butting in, apologies. It may not have been Jim's intention below, but I get the impression that his comments on CPAN are a bit harsh. It is true that a number of modules are apparently no longer supported. I have used many modules over the years, and sometimes have had problems with some of them (mostly not though). And when for these problematic cases, I have tried to get help, the results have beem mixed; but the mix for me has been rather good. I would say that in my case, 90% of the CPAN modules I ever used worked out of the box. For the 10% remaining, in 75% of the cases I did get help from the person advertised as the author or the maintainer, and in 25% of cases I never got a response. But then, as Jim himself indicated, people move on, without necessarily changing their email addresses. Considering how old some of these modules are, I guess people also retire, or even pass away. But the fact of the matter is that CPAN is still an incredible resource, unequalled in my view by any other similar module library of any other language anywhere. And I find it amazing that at least 90% of the modules which I have downloaded from CPAN and used over the last 15 years, just work, and moreover keep on working through many, many iterations of programs and perl versions, and that in fact one very rarely needs additional support for them. When I compare this with other programming languages and support libraries, I believe we perl programmers are incredibly spoiled. Another area where CPAN shines, is the documentation of most modules. I cannot count the times where I was faced with a request in an area of which I knew nothing at all, and have just browsed CPAN for modules related to that area, just to read their documentation and get at least an idea of what this was all about. In recent years, Wikipedia may slowly becoming a runner-up, in terms of general information. But when it comes down to the nitty-gritty of interfacing with whatever API (or lack of ditto) programmers in their most delirious moments might have come up with, these CPAN modules are unbeatable. Even if after that you decide to program your stuff in another language than perl, it's still useful. (Just for fun, go into CPAN and search for "NATO" (or more pragmatically, for "sharepoint" e.g.)(or even, God forbid, for "Google" or "Facebook" ;-)); who thinks of such things ?) So, to summarise : that some modules on CPAN would be marked as "maintained" or "supported" and would turn out on closer inspection not to really be anymore, I find this a very small price to pay for the wealth of good information and working code that lives there. My sincerest thanks to CPAN and all its contributors and maintainers over the years (that includes you of course, Jim). What you have done and are doing is of incredible benefit to many, many programmers worldwide. André Jim Schueler wrote: I still use Alpine. And they never fixed the bug where ctrl-c (to cancel a message) and ctrl-x (to send) are so easily confused. Oops. Maybe it's time to start using a mouse. Having wasted so much time, I'll try to be succinct: Most modules on CPAN are bascially throwaways and not supported at all. Use them at your own risk. There are some modules that are just obsolete. Good intentions aside, the developers lost interest and moved on. These are less risky if there's an established user base. There are some very good modules, widely used, that are fully supported and perfectly safe for a production environment. Most mod_perl modules, especially the core modules, fall into that last, gold standard, category. In many cases, support is transferred from one individual to another. And so that commi
Re: [OT] Apache::DBI
Jim Schueler wrote: No apology please. In terms of trying to qualify any of this, a larger statistical pool is better. And I am no authority. My perceptions are largely based on forum postings which causes an inherent bias. I'd love to see this conversation continue, especially if participants included those who commit significant resources to their technology decisions. In other words, people who hire and pay Perl programmers. They're likely to be as skeptical as I am. I've never been a cheerleader. In their absence, I'd note that your post has an interesting ambiguity: Is the number of unsupported modules 2.5% or 25%? Note that this was prefixed by "for the 10% remaining,", so it was indeed 2.5%. My mothertongue is not English, so I am subject to the occasional linguistic slippage. It would probably have been clearer had I written "Of the remaining 10%,". (For more rhetorical nit-picking, you probably don't use the ones that don't work :) Maybe. But I do use quite a few that do work and never needed any support. And there are thousands of add-on modules in other languages that don't work and that I don't use either. (So where does that leave us, statistically speaking ?) I believe that Vincent's comment is right on the spot : perl, and perl CPAN modules, and mod_perl, generally work so well that there are not a lot of support requests, and that situation by itself makes them rather "transparent". "Happy people have no History" (French proverb, translated literally). There is a similar situation elsewhere in the IT world : some environments or applications need a lot of support just to keep running. Therefore, they need a large support staff. Therefore, their department grows larger and their boss gets a lot of clout and a big budget. In contrast, the application which just works and doesn't require much support, does not make headlines, tends to get forgotten and gets less staff, a smaller boss and a smaller budget. Unfair but often seen. Maybe the perl situation is not so bad in reality though. I have it from some usually reliable sources that there is a gradual regain of popularity of perl among younger programmers. That is certainly the case among the young programmers that I employ. They usually arrive all infatuated by things java and PHP and .net and sharp, and look sceptically at best upon anything around perl. Then they are asked to solve some simple issues, and pick their preferred language to do it. Then they are shown the perl way of doing it, and that generally succeeds in getting their attention. It's a slow process, but one has to patiently overcome years of Java and MS propaganda, and that doesn't happen in a day. Also, the significant question seems to be whether Apache::DBI is supported or not. From Mr. Zheng's point-of-view (in this case, the one that matters) the number might be much higher. -Jim On Fri, 31 May 2013, André Warnier wrote: Just butting in, apologies. It may not have been Jim's intention below, but I get the impression that his comments on CPAN are a bit harsh. It is true that a number of modules are apparently no longer supported. I have used many modules over the years, and sometimes have had problems with some of them (mostly not though). And when for these problematic cases, I have tried to get help, the results have beem mixed; but the mix for me has been rather good. I would say that in my case, 90% of the CPAN modules I ever used worked out of the box. For the 10% remaining, in 75% of the cases I did get help from the person advertised as the author or the maintainer, and in 25% of cases I never got a response. But then, as Jim himself indicated, people move on, without necessarily changing their email addresses. Considering how old some of these modules are, I guess people also retire, or even pass away. But the fact of the matter is that CPAN is still an incredible resource, unequalled in my view by any other similar module library of any other language anywhere. And I find it amazing that at least 90% of the modules which I have downloaded from CPAN and used over the last 15 years, just work, and moreover keep on working through many, many iterations of programs and perl versions, and that in fact one very rarely needs additional support for them. When I compare this with other programming languages and support libraries, I believe we perl programmers are incredibly spoiled. Another area where CPAN shines, is the documentation of most modules. I cannot count the times where I was faced with a request in an area of which I knew nothing at all, and have just browsed CPAN for modules related to that area, just to read their documentation and get at least an idea of what this was all about. In recent years, Wikipedia may slowly becoming a runner-up, in te
Re: [OT] Apache::DBI
Just butting in, apologies. It may not have been Jim's intention below, but I get the impression that his comments on CPAN are a bit harsh. It is true that a number of modules are apparently no longer supported. I have used many modules over the years, and sometimes have had problems with some of them (mostly not though). And when for these problematic cases, I have tried to get help, the results have beem mixed; but the mix for me has been rather good. I would say that in my case, 90% of the CPAN modules I ever used worked out of the box. For the 10% remaining, in 75% of the cases I did get help from the person advertised as the author or the maintainer, and in 25% of cases I never got a response. But then, as Jim himself indicated, people move on, without necessarily changing their email addresses. Considering how old some of these modules are, I guess people also retire, or even pass away. But the fact of the matter is that CPAN is still an incredible resource, unequalled in my view by any other similar module library of any other language anywhere. And I find it amazing that at least 90% of the modules which I have downloaded from CPAN and used over the last 15 years, just work, and moreover keep on working through many, many iterations of programs and perl versions, and that in fact one very rarely needs additional support for them. When I compare this with other programming languages and support libraries, I believe we perl programmers are incredibly spoiled. Another area where CPAN shines, is the documentation of most modules. I cannot count the times where I was faced with a request in an area of which I knew nothing at all, and have just browsed CPAN for modules related to that area, just to read their documentation and get at least an idea of what this was all about. In recent years, Wikipedia may slowly becoming a runner-up, in terms of general information. But when it comes down to the nitty-gritty of interfacing with whatever API (or lack of ditto) programmers in their most delirious moments might have come up with, these CPAN modules are unbeatable. Even if after that you decide to program your stuff in another language than perl, it's still useful. (Just for fun, go into CPAN and search for "NATO" (or more pragmatically, for "sharepoint" e.g.)(or even, God forbid, for "Google" or "Facebook" ;-)); who thinks of such things ?) So, to summarise : that some modules on CPAN would be marked as "maintained" or "supported" and would turn out on closer inspection not to really be anymore, I find this a very small price to pay for the wealth of good information and working code that lives there. My sincerest thanks to CPAN and all its contributors and maintainers over the years (that includes you of course, Jim). What you have done and are doing is of incredible benefit to many, many programmers worldwide. André Jim Schueler wrote: I still use Alpine. And they never fixed the bug where ctrl-c (to cancel a message) and ctrl-x (to send) are so easily confused. Oops. Maybe it's time to start using a mouse. Having wasted so much time, I'll try to be succinct: Most modules on CPAN are bascially throwaways and not supported at all. Use them at your own risk. There are some modules that are just obsolete. Good intentions aside, the developers lost interest and moved on. These are less risky if there's an established user base. There are some very good modules, widely used, that are fully supported and perfectly safe for a production environment. Most mod_perl modules, especially the core modules, fall into that last, gold standard, category. In many cases, support is transferred from one individual to another. And so that commitment is documented. But if a module is no longer supported, don't lie about it. Support forums are an incredible resource. But if commercial software developers similarly blurred this distinction, every p.o.s. would be advertising free 24x7 tech support. Apache::DBI seems like a #2 pretending to be a #3. On the basis of your response, I've concluded that Apache::DBI is no longer supported and has been superceded by newer modules. Especially if no one responds and explicitly accepts the responsibility, this seems like the most appropriate answer for the poster of the original thread. I owe you a :) from a couple posts ago. :) -Jim On Fri, 31 May 2013, Perrin Harkins wrote: Hi Jim, I appreciate the thought, but I'm not the mod_perl list. If you look at who has done the most support around here recently, it's probably Torsten. (Thanks Torsten!) More to the point, there are many people on the list who know enough perl to help with a question about Apache::DBI. It's a common practice to point people here for support on mod_perl modules. What are you getting at? Is there a module that you're having trouble with and can't get support for? - Perrin On Fri, May 31, 2013 at
Re: Perl module not reading/setting PerlSetEnv command on apache start
jitendra.s...@accenture.com wrote: I tried with /AMF path also with folder owner as "nobody" then also while starting apache its saying CacheDirectoryStore not exits.I tried following steps: (1) sudo su (that is for root user login) (2) Created folder AMF with owner as nobody. (3) Set PerlSetEnv CacheDirectoryStore /AMf (4) Restarted apache and got error CacheDirectoryStore not exits. Don't know what is missing from my side?? Neither do we, really. You may have better luck a the the support address for the add-on module that you are using : http://groups.google.com/group/amf-device-detection - Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: Vincent Veyron [mailto:vv.li...@wanadoo.fr] Sent: Monday, May 13, 2013 9:11 PM To: Soni, Jitendra Cc: modperl@perl.apache.org Subject: RE: Perl module not reading/setting PerlSetEnv command on apache start Le lundi 13 mai 2013 à 13:45 +, jitendra.s...@accenture.com a écrit : But I have given chmod 777 to these folder, will then also it won't work?? It's not only these folders that must be accessible, the whole tree above them has to be executable by the Apache user. -- Salutations, Vincent Veyron http://marica.fr/site/demonstration Logiciel de gestion des contentieux juridiques et des sinistres d'assurance This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com
Re: Perl module not reading/setting PerlSetEnv command on apache start
Hi. You need help, but probably not from this list. You need help from someone who knows - about user/directory permissions on the specific platform that you are using, apparently "sunos sz1061 5.10 generic_147440-19 sun4u sparc sunw,sparc-enterprise", and specifically about the user "nobody" on that platform - about running Apache on this platform under a user-id different from "nobody", and the corresponding security implications The problem that you are having has nothing to do with perl or mod_perl per se. You would have the same problem with any Apache add-on module which tries to write to a disk file, whether that module is written in C or any other language. The point is not that the PerlSetEnv is not working. It seems to be working fine. The point is that the add-on module runs under the same user-id as Apache itself; and it tries to write to a disk directory to which (apparently) this user-id has no write permission. So you need to change either the user-id of Apache, or the permissions of the directory, but neither of these changes is "neutral" in terms of the system security. That's why you need competent help at that level. jitendra.s...@accenture.com wrote: But I have given chmod 777 to these folder, will then also it won't work?? Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: Joakim Tørmoen [mailto:joakim.torm...@evry.com] Sent: Monday, May 13, 2013 7:10 PM To: Soni, Jitendra; modperl@perl.apache.org Subject: RE: Perl module not reading/setting PerlSetEnv command on apache start Hi, It has nothing to do with perl... You are running apache as nobody\nobody and trying to read/write something under /home/soni498/AMF/cache/ and /home/AMF On standard linux systems this is not possible unless you have changed the standard permissons on these folders. (And that is not recommended) Best regards Joakim From: jitendra.s...@accenture.com [jitendra.s...@accenture.com] Sent: Monday, May 13, 2013 3:22 PM To: modperl@perl.apache.org Subject: RE: Perl module not reading/setting PerlSetEnv command on apache start Actually I am new to perl and need some help in fixing this issue. Do I need to change the User to ROOT in conf file then start apache?? Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, May 13, 2013 6:47 PM To: mod_perl list Subject: Re: Perl module not reading/setting PerlSetEnv command on apache start jitendra.s...@accenture.com wrote: I am starting apache with ROOT user and apache is configured with below User/Group like below. Is this causing any issue? That is probably the issue indeed. I believe that you can probably figure out the rest by yourself. # don't use Group #-1 on these systems! # User nobody Group nobody # Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, May 13, 2013 6:16 PM To: mod_perl list Subject: Re: Perl module not reading/setting PerlSetEnv command on apache start The error message says : 09/05/13 - 12:05:17 - CacheDirectoryStore not exist.Please set the variable CacheDirectoryStore into httpd.conf, (the directory must be writeable) Are you sure that this directory exists and is writeable (by the user-id under which Apache runs) ? jitendra.s...@accenture.com wrote: Hi Andre, Because I have set CacheDirectoryStore in my httpd conf file but it's not read by AMF51DegreesFilter.pm file while starting apache. Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, May 13, 2013 5:59 PM To: mod_perl list Subject: Re: Perl module not reading/setting PerlSetEnv command on apache start Hi. And what makes you think that this is a mod_perl problem ? There is a fairly explicit error message (and support address) below, which tends to point to a problem in the add-on module or the configuration. jitendra.s...@accenture.com wrote: Gentlemen, I need urgent help from you in fixing issue related to apache mobile filter 3.53. On putting below AMF configuration in apache httpd conf file I am not able to start apache. Below is the AMF configuration I have added in httpd conf: # #Configuration
Re: Perl module not reading/setting PerlSetEnv command on apache start
jitendra.s...@accenture.com wrote: I am starting apache with ROOT user and apache is configured with below User/Group like below. Is this causing any issue? That is probably the issue indeed. I believe that you can probably figure out the rest by yourself. # don't use Group #-1 on these systems! # User nobody Group nobody # Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, May 13, 2013 6:16 PM To: mod_perl list Subject: Re: Perl module not reading/setting PerlSetEnv command on apache start The error message says : 09/05/13 - 12:05:17 - CacheDirectoryStore not exist.Please set the variable CacheDirectoryStore into httpd.conf, (the directory must be writeable) > Are you sure that this directory exists and is writeable (by the user-id under which Apache runs) ? jitendra.s...@accenture.com wrote: Hi Andre, Because I have set CacheDirectoryStore in my httpd conf file but it's not read by AMF51DegreesFilter.pm file while starting apache. Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, May 13, 2013 5:59 PM To: mod_perl list Subject: Re: Perl module not reading/setting PerlSetEnv command on apache start Hi. And what makes you think that this is a mod_perl problem ? There is a fairly explicit error message (and support address) below, which tends to point to a problem in the add-on module or the configuration. jitendra.s...@accenture.com wrote: Gentlemen, I need urgent help from you in fixing issue related to apache mobile filter 3.53. On putting below AMF configuration in apache httpd conf file I am not able to start apache. Below is the AMF configuration I have added in httpd conf: # #Configuration AMF Filter # PerlSetEnv AMFMobileHome /home/AMF #PerlSetEnv AMFProductionMode true PerlSetEnv CacheDirectoryStore /home/soni498/AMF/cache/ PerlTransHandler +Apache2::AMF51DegreesFilter # #Configuration Switcher # PerlSetEnv WildCardRedirect false PerlSetEnv ForceTabletAsFullBrowser false PerlSetEnv FullBrowserUrl http://sz1061.app.gen.local:83 PerlSetEnv MobileVersionUrl http://sz1061.app.gen.local:83/m/ PerlTransHandler +Apache2::AMFSwitcher -8<-- Start Bug Report 8<-- 1. Problem Description: Perl module not reading/setting the PerlSetEnv command, hence not getting CacheDirectoryStore value while stating apache. See error below: (1) While starting below error we are getting # ./apachectl.e.83 -k start 09/05/13 - 12:05:17 - --- 09/05/13 - 12:05:17 - --- APACHE MOBILE FILTER V3.54 --- 09/05/13 - 12:05:17 - --- support http://groups.google.com/group/amf-device-detection --- 09/05/13 - 12:05:17 - - -- 09/05/13 - 12:05:17 - AMF51DegreesFilter module Version 3.54 09/05/13 - 12:05:17 - AMFCheckVersione is false, AMF don't check the last version. 09/05/13 - 12:05:17 - CacheDirectoryStore not exist.Please set the variable CacheDirectoryStore into httpd.conf, (the directory must be writeable) (2) In apache logs we are getting below error: [Mon May 13 13:16:39 2013] [info] mod_ssl/2.2.20 compiled against Server: Apache/2.2.20, Library: OpenSSL/0.9.8k Mon May 13 13:16:39 2013] [error] ModPerl::Util::exit: (12) exit was called at /usr/local/lib/perl5/site_perl/5.14.2/Apache2/AMF51DegreesFilter.pm line 128Compilation failed in require at (eval 2) line 2.\n failed to load Apache2::AMF51DegreesFilter package 2. Used Components and their Configuration: *** mod_perl version 2.07 *** using /home/soni498/mod_perl-2.0.7/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/apache02/httpd_2.2.20/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /usr/httpd2.2.20/httpd/bin/httpd -V Server version: Apache/2.2.20 (Unix) Server built: Feb 5 2013 08:10:24 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SI
Re: Perl module not reading/setting PerlSetEnv command on apache start
The error message says : 09/05/13 - 12:05:17 - CacheDirectoryStore not exist.Please set the variable CacheDirectoryStore into httpd.conf, (the directory must be writeable) > Are you sure that this directory exists and is writeable (by the user-id under which Apache runs) ? jitendra.s...@accenture.com wrote: Hi Andre, Because I have set CacheDirectoryStore in my httpd conf file but it's not read by AMF51DegreesFilter.pm file while starting apache. Met vriendelijke groet / With kind regards, Jitendra Soni KPN - Application Development Accenture | Bangalore INDIA Mailto : jitendra.s...@accenture.com Mobile : (+91) 99 860 298 97 -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, May 13, 2013 5:59 PM To: mod_perl list Subject: Re: Perl module not reading/setting PerlSetEnv command on apache start Hi. And what makes you think that this is a mod_perl problem ? There is a fairly explicit error message (and support address) below, which tends to point to a problem in the add-on module or the configuration. jitendra.s...@accenture.com wrote: Gentlemen, I need urgent help from you in fixing issue related to apache mobile filter 3.53. On putting below AMF configuration in apache httpd conf file I am not able to start apache. Below is the AMF configuration I have added in httpd conf: # #Configuration AMF Filter # PerlSetEnv AMFMobileHome /home/AMF #PerlSetEnv AMFProductionMode true PerlSetEnv CacheDirectoryStore /home/soni498/AMF/cache/ PerlTransHandler +Apache2::AMF51DegreesFilter # #Configuration Switcher # PerlSetEnv WildCardRedirect false PerlSetEnv ForceTabletAsFullBrowser false PerlSetEnv FullBrowserUrl http://sz1061.app.gen.local:83 PerlSetEnv MobileVersionUrl http://sz1061.app.gen.local:83/m/ PerlTransHandler +Apache2::AMFSwitcher -8<-- Start Bug Report 8<-- 1. Problem Description: Perl module not reading/setting the PerlSetEnv command, hence not getting CacheDirectoryStore value while stating apache. See error below: (1) While starting below error we are getting # ./apachectl.e.83 -k start 09/05/13 - 12:05:17 - --- 09/05/13 - 12:05:17 - --- APACHE MOBILE FILTER V3.54 --- 09/05/13 - 12:05:17 - --- support http://groups.google.com/group/amf-device-detection --- 09/05/13 - 12:05:17 - --- 09/05/13 - 12:05:17 - AMF51DegreesFilter module Version 3.54 09/05/13 - 12:05:17 - AMFCheckVersione is false, AMF don't check the last version. 09/05/13 - 12:05:17 - CacheDirectoryStore not exist.Please set the variable CacheDirectoryStore into httpd.conf, (the directory must be writeable) (2) In apache logs we are getting below error: [Mon May 13 13:16:39 2013] [info] mod_ssl/2.2.20 compiled against Server: Apache/2.2.20, Library: OpenSSL/0.9.8k Mon May 13 13:16:39 2013] [error] ModPerl::Util::exit: (12) exit was called at /usr/local/lib/perl5/site_perl/5.14.2/Apache2/AMF51DegreesFilter.pm line 128Compilation failed in require at (eval 2) line 2.\n failed to load Apache2::AMF51DegreesFilter package 2. Used Components and their Configuration: *** mod_perl version 2.07 *** using /home/soni498/mod_perl-2.0.7/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/apache02/httpd_2.2.20/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /usr/httpd2.2.20/httpd/bin/httpd -V Server version: Apache/2.2.20 (Unix) Server built: Feb 5 2013 08:10:24 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/usr/httpd2.2.20/httpd" -D SUEXEC_BIN="/usr/httpd2.2.20/httpd/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** /usr/bin/ldd /usr/httpd2.2.20/httpd/bin/httpd libm.so.2 => /lib/libm.so.2 libaprutil-1.so.0 => /usr/httpd2.2.20/httpd/lib/libaprutil-1.so.0 libexpat.so.0 => /usr/httpd2.2.20/httpd/lib/lib
Re: Perl module not reading/setting PerlSetEnv command on apache start
Hi. And what makes you think that this is a mod_perl problem ? There is a fairly explicit error message (and support address) below, which tends to point to a problem in the add-on module or the configuration. jitendra.s...@accenture.com wrote: Gentlemen, I need urgent help from you in fixing issue related to apache mobile filter 3.53. On putting below AMF configuration in apache httpd conf file I am not able to start apache. Below is the AMF configuration I have added in httpd conf: # #Configuration AMF Filter # PerlSetEnv AMFMobileHome /home/AMF #PerlSetEnv AMFProductionMode true PerlSetEnv CacheDirectoryStore /home/soni498/AMF/cache/ PerlTransHandler +Apache2::AMF51DegreesFilter # #Configuration Switcher # PerlSetEnv WildCardRedirect false PerlSetEnv ForceTabletAsFullBrowser false PerlSetEnv FullBrowserUrl http://sz1061.app.gen.local:83 PerlSetEnv MobileVersionUrl http://sz1061.app.gen.local:83/m/ PerlTransHandler +Apache2::AMFSwitcher -8<-- Start Bug Report 8<-- 1. Problem Description: Perl module not reading/setting the PerlSetEnv command, hence not getting CacheDirectoryStore value while stating apache. See error below: (1) While starting below error we are getting # ./apachectl.e.83 -k start 09/05/13 - 12:05:17 - --- 09/05/13 - 12:05:17 - --- APACHE MOBILE FILTER V3.54 --- 09/05/13 - 12:05:17 - --- support http://groups.google.com/group/amf-device-detection --- 09/05/13 - 12:05:17 - --- 09/05/13 - 12:05:17 - AMF51DegreesFilter module Version 3.54 09/05/13 - 12:05:17 - AMFCheckVersione is false, AMF don't check the last version. 09/05/13 - 12:05:17 - CacheDirectoryStore not exist.Please set the variable CacheDirectoryStore into httpd.conf, (the directory must be writeable) (2) In apache logs we are getting below error: [Mon May 13 13:16:39 2013] [info] mod_ssl/2.2.20 compiled against Server: Apache/2.2.20, Library: OpenSSL/0.9.8k Mon May 13 13:16:39 2013] [error] ModPerl::Util::exit: (12) exit was called at /usr/local/lib/perl5/site_perl/5.14.2/Apache2/AMF51DegreesFilter.pm line 128Compilation failed in require at (eval 2) line 2.\n failed to load Apache2::AMF51DegreesFilter package 2. Used Components and their Configuration: *** mod_perl version 2.07 *** using /home/soni498/mod_perl-2.0.7/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/apache02/httpd_2.2.20/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /usr/httpd2.2.20/httpd/bin/httpd -V Server version: Apache/2.2.20 (Unix) Server built: Feb 5 2013 08:10:24 Server's Module Magic Number: 20051115:28 Server loaded: APR 1.4.5, APR-Util 1.3.12 Compiled using: APR 1.4.5, APR-Util 1.3.12 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/usr/httpd2.2.20/httpd" -D SUEXEC_BIN="/usr/httpd2.2.20/httpd/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** /usr/bin/ldd /usr/httpd2.2.20/httpd/bin/httpd libm.so.2 => /lib/libm.so.2 libaprutil-1.so.0 => /usr/httpd2.2.20/httpd/lib/libaprutil-1.so.0 libexpat.so.0 => /usr/httpd2.2.20/httpd/lib/libexpat.so.0 libiconv.so.2 => /usr/local/lib/libiconv.so.2 libapr-1.so.0 => /usr/httpd2.2.20/httpd/lib/libapr-1.so.0 libuuid.so.1 => /lib/libuuid.so.1 libsendfile.so.1 => /lib/libsendfile.so.1 librt.so.1 =>/lib/librt.so.1 libsocket.so.1 =>/lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libaio.so.1 => /lib/libaio.so.1 libmd.so.1 =>/lib/libmd.so.1 libmp.so.2 =>/lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 /lib/libm/libm_hwcap1.so.2 /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1 *** (apr|apu)-config linking info -L/usr/apache02/httpd_2.2.20/lib
problems with CPAN
Hi. I understand that this is not properly speaking a mod_perl issue, more like a perl/cpan issue under Windows. But before I go subscribe to a couple more lists, maybe someone on this list has a clue and can help ? I recently update perl on my venerable Windows XP laptop, from ActivePerl 5.8 to 5.16, then reverted to 5.14, then finally switched to Strawberry Perl 5.16 : perl -v : This is perl 5, version 16, subversion 3 (v5.16.3) built for MSWin32-x86-multi-thread ... The reason for these multiple switches was the difficulty in getting pre-compiled binary modules for some of the versions above (including mod_perl). Anyway, in the course of the above tribulations, I did encounter at some point the same issue as below, and I wonder where the problem really is. I am providing the full trace, but you can see the main issue in the last 10 lines : at some point, there is a message like : C:sperlperlbinperl.exe: not found and after that nothing works anymore. In this case, C:\sperl\perl\bin\perl.exe points to the installation directory of StrawbwerryPerl v5.16.3. But I've seen the same issue before with ActivePerl installed, so I presume that the real problem is somewhere in the CPAN modules themselves or in dmake or in the make files. Looks like something is interpreting this path like a "string" instead of a 'string', and unescaping the backslashes. But I'm just a user of perl,and I don't really know how these things are supposed to work. Does someone here know ? C:\WINDOWS>cpan MIME::Lite CPAN: CPAN::SQLite loaded ok (v0.202) CPAN: LWP::UserAgent loaded ok (v6.04) CPAN: Time::HiRes loaded ok (v1.9725) Fetching with LWP: http://cpan.strawberryperl.com/authors/01mailrc.txt.gz CPAN: YAML::XS loaded ok (v0.39) Fetching with LWP: http://cpan.strawberryperl.com/modules/02packages.details.txt.gz Fetching with LWP: http://cpan.strawberryperl.com/modules/03modlist.data.gz Creating database file ... Done!Running install for module 'MIME::Lite' Running make for R/RJ/RJBS/MIME-Lite-3.029.tar.gz Fetching with LWP: http://cpan.strawberryperl.com/authors/id/R/RJ/RJBS/MIME-Lite-3.029.tar.gz CPAN: Digest::SHA loaded ok (v5.84) Fetching with LWP: http://cpan.strawberryperl.com/authors/id/R/RJ/RJBS/CHECKSUMS CPAN: Compress::Zlib loaded ok (v2.06) Checksum for C:\sperl\cpan\sources\authors\id\R\RJ\RJBS\MIME-Lite-3.029.tar.gz ok CPAN: Archive::Tar loaded ok (v1.90) CPAN: File::Temp loaded ok (v0.22) CPAN: Parse::CPAN::Meta loaded ok (v1.4404) CPAN: CPAN::Meta loaded ok (v2.120921) CPAN: Module::CoreList loaded ok (v2.83) CPAN.pm: Building R/RJ/RJBS/MIME-Lite-3.029.tar.gz MIME::Lite is designed to take advantage of a variety of external modules if they are not present then MIME::Lite will attempt to do its best but its strongly recommend that you install them. These modules are: MIME::Types Mail::Address I can add these modules to the prereq list which will cause the files to be automatically installed if they aren't already present Add prereqs? [Yes] Checking if your kit is complete... Looks good Warning: prerequisite Email::Date::Format 1.000 not found. Warning: prerequisite MIME::Types 1.28 not found. Warning: prerequisite Mail::Address 1.62 not found. Writing Makefile for MIME::Lite Writing MYMETA.yml and MYMETA.json Unsatisfied dependencies detected during RJBS/MIME-Lite-3.029.tar.gz Email::Date::Format [requires] Mail::Address [requires] MIME::Types [requires] Running make test Delayed until after prerequisites Running make install Delayed until after prerequisites Running install for module 'Email::Date::Format' Running make for R/RJ/RJBS/Email-Date-Format-1.002.tar.gz Fetching with LWP: http://cpan.strawberryperl.com/authors/id/R/RJ/RJBS/Email-Date-Format-1.002.tar.gz Checksum for C:\sperl\cpan\sources\authors\id\R\RJ\RJBS\Email-Date-Format-1.002.tar.gz ok CPAN.pm: Building R/RJ/RJBS/Email-Date-Format-1.002.tar.gz Checking if your kit is complete... Looks good Writing Makefile for Email::Date::Format Writing MYMETA.yml and MYMETA.json C:sperlperlbinperl.exe: not found dmake.exe: Error code 255, while making 'blib\lib\Email\Date\.exists' RJBS/Email-Date-Format-1.002.tar.gz C:\sperl\c\bin\dmake.exe -- NOT OK Running make test Can't test without successful make Running make install Make had returned bad status, install seems impossible Stopping: 'install' failed for 'Email::Date::Format'. C:\WINDOWS>
Re: Mod_perl installation on Win 2008
ext-ma wrote: Hi. I am a consultant for a high-tech company and I have installed Bugzilla for their internal use. For various reasons the Apache server had to be installed on a Win2008 server. And for other reasons the server is Apache 2.0. I thought you said that this is a hi-tech company.. The mod_perl module is missing from Apache and hence Bugzilla is slow. I have read about this and found various ways to install mod_perl. http://perl.apache.org/docs/2.0/os/win32/install.html is a good link. Problem is that almost all these advices points to either http://theoryx5.uwinnipeg.ca/ or http://cpan.uwinnipeg.ca/ and both these addresses have been down for over a day. It might be that I am missing something obvious but would anyway appreciate some help. The less-than-obvious thing is that I believe that the person who took care of these sites has passed away (died), and nobody else has taken up the work of maintaining these sites. A pity, really. Look in the archives of this list, just a few days ago, for a link to another site providing some mod_perl binaries. They are not the ones you need, but maybe the same person can help you. http://people.apache.org/~stevehay/
Apache option MultiViews interfering with mod_perl
Hi. It is quite certain that the basic reason for my troubles is my own lack of expertise, but I suppose that others may stumble into the same issue at some point, and this may help them avoid the loss of time involved. Basically, I had an Apache (2.2) configuration section as follows : PerlAccessHandler my::module->access PerlFixupHandler my::module->fixup SetHandler modperl PerlResponseHandler my::module->login PerlSetVar my_login_form "/login.html" As you can probably guess, this is part of a self-written authentication mechanism derived from Apache::AuthCookie, and the login form that is used is the document at (DocumentRoot)/login.html. Now this has worked fine on dozens of servers so far, for several years. But then unexpectedly on this new similar webserver that I just set up, it didn't work anymore, in a quite peculiar way : - the above PerlAccessHandler was run fine, and logged everything as normally - but neither the PerlFixupHandler nor the PerlResponseHandler were being run, without any error or trace at all in the logs. Instead, all I got was the login document in the browser, but in a way that showed that it was delivered straight from the disk, without going through the response-handler at all (which it normally does). It was also quite puzzling because how could it respond with "/login.html" when I requested "/login", and how could it nevertheless show a POST to "/login", with a response code 200 OK in the access log. Did Apache somehow start behaving like hateful end-user software, divining what was good for me, instead of what I explicitly said I wanted ? To make a long story shorter (by 2 days), I finally realised that it was because in this particular server, there was a unique coincidence of two elements : - the DocumentRoot directory of the server had a "Options MultiViews" added to it - my login document was "/login.html" And why the problem happened was this stanza in the Apache on-line documentation of the Options directive (and/or mod_negociation) : quote MultiViews A MultiViews search is enabled by the MultiViews Options. If the server receives a request for /some/dir/foo and /some/dir/foo does not exist, then the server reads the directory looking for all files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's.. unquote So what happened here was : - the PerlAccessHandler was run normally, as it happens quite early in the Apache cycle, before Apache even starts to map the URL to a file on disk - then somewhere mod_negociation takes over. It looks at the requested URL (/login), and does not find a corresponding directory "(DocumentRoot)/login". So then, it looks in the directory "/", trying to find anything that looks like "login.*". In this case, it finds "/login.html". So it sets things up to return "/login.html" as the response. Predictable and fair enough, one could say. Except that in the process it *disables* the other configuration lines which should have invoked the fixup handler and mod_perl as the response handler, and these are never run. Instead, it seemingly runs the Apache default handler, which just returns the file. Removing the MultiViews option made things get back to normal. Changing the name of the login form to something not matching "/login" so closely also does the trick. But it took me close to two days to figure this out, mainly because I have dozens of other servers which have exactly the same section and are doing fine, and I just never realised that this MultiViews Option, inherited from way back up there in the configuration, could have such a drastic effect. HTH someone some day.
Re: New Windows mod_perl binaries available
Steve Hay wrote: No problem! I've just uploaded builds for ActivePerl 1405 (5.14.4) and StrawberryPerl 5.14.4.1, which you can find in the same location as before: http://people.apache.org/~stevehay/ Thanks. You had your first customer for all 4 of them 2 minutes ago. Really grateful. Can someone get the corresponding page in the mod_perl online docs updated to point to this, if Steve doesn't mind ? It would surely save a lot of people a lot of aggravation.
Re: New Windows mod_perl binaries available
Randolf Richardson wrote: For those who are interested, I've now uploaded binary builds of mod_perl-2.0.8 and libapreq2-2.13 components compatible with Apache Lounge 2.2.24 Build 25 February 2013 (win32) and each of: * ActivePerl 5.16.3 Build 1603 (x86) * Strawberry Perl 5.16.3 Build 1 (32bit) You can download them from http://people.apache.org/~stevehay/ Please let me know if you have any problems. Thank you for making these available Steve. It's very helpful to folks like myself who have trouble reliably generating binaries for the Microsoft Windows OS, but would like to introduce others to it who aren't starting out with any of the Unix or Linux OSes. +1 (actually, more than +1, as we are quite a few people here using your binaries) Are there any plans of getting 64-bit versions compiled too, or is there some complication with doing this on Windows? Any chance of a version for Activestate Perl 5.14 ? (personally, 32-bit) Reason : I had also started with 5.16, but then it seems that a lot of modules are not yet available for that version as ppm, so I reverted back to 5.14 for now.
ActivePerl 5.16 & CPAN
Hi. I know this is a mod_perl list, not a perl list per se, but maybe someone here knows the issue.. On my Windows XP laptop, I have just de-installed my old Perl 5.10 and installed ActivePerl 5.16 (which caused some issues with mod_perl now resolved, see previous post today). But I am having another problem : whenever I try to install a CPAN module, it starts nicely enough, but then invariably crashes at some point with a message : C:Perlbinperl.exe: not found dmake.exe: Error code 255, while making 'blib\lib\.exists' (a more lengthy excerpt below). I figure that it must be misinterpreting the backslashes in the path to Perl (which is at C:\perl\bin\perl), but I cannot imagine that I would be the only one to have experienced this. Any clue as to how to fix this ? More output lines of an example, trying to install Template::Toolkit : ... AppConfig-1.66/t/novars.t AppConfig-1.66/t/state.t AppConfig-1.66/t/sys.t AppConfig-1.66/TODO CPAN.pm: Building A/AB/ABW/AppConfig-1.66.tar.gz Set up gcc environment - 3.4.5 (mingw-vista special r3) Checking if your kit is complete... Looks good Writing Makefile for AppConfig Writing MYMETA.yml and MYMETA.json C:Perlbinperl.exe: not found dmake.exe: Error code 255, while making 'blib\lib\.exists' ABW/AppConfig-1.66.tar.gz C:\Perl\site\bin\dmake.exe -- NOT OK CPAN: YAML::XS loaded ok (v0.39) Running make test Can't test without successful make Running make install Make had returned bad status, install seems impossible Running make for A/AB/ABW/Template-Toolkit-2.24.tar.gz Has already been unwrapped into directory C:\Perl\cpan\build\Template-Toolkit CPAN.pm: Building A/AB/ABW/Template-Toolkit-2.24.tar.gz Warning: Prerequisite 'AppConfig => 1.56' for 'ABW/Template-Toolkit-2.24.tar.gz .66.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited. CPAN: Time::HiRes loaded ok (v1.9725) C:Perlbinperl.exe: not found dmake.exe: Error code 255, while making 'blib\lib\.exists' ABW/Template-Toolkit-2.24.tar.gz C:\Perl\site\bin\dmake.exe -- NOT OK Running make test Can't test without successful make Running make install Make had returned bad status, install seems impossible C:\Perl\bin> ... Output of perl -V : C:\Perl\bin>perl -V Set up gcc environment - 3.4.5 (mingw-vista special r3) Summary of my perl5 (revision 5 version 16 subversion 3) configuration: Platform: osname=MSWin32, osvers=5.2, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='C:\Perl\site\bin\gcc.exe', ccflags ='-DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DUSE_SITEC USTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T -DHASATTRIBUTE -fno-strict-aliasin g -mms-bitfields', optimize='-O2', cppflags='-DWIN32' ccversion='', gccversion='3.4.5 (mingw-vista special r3)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='C:\Perl\site\bin\g++.exe', ldflags ='-L"C:\Perl\lib\CORE"' libpth=\lib libs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lw s2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt perllibs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl516.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -L"C:\Perl\lib\CORE"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1603 [296746] Built under MSWin32 Compiled at Mar 13 2013 11:29:21 @INC: C:/Perl/site/lib C:/Perl/lib . C:\Perl\bin>
Re: Windows XP, Apache, perl 5.16, mod_perl
Michiel Beijen wrote: Hi Andre, On Fri, April 5, 2013 15:31, André Warnier wrote: Could you recommend one "integrated" solution for this, in terms of Apache httpd 2.2.x, and a recent perl version ? Like, something which works without having to spend a week resolving dependencies and incompatibilities ? Steve Hay compiled mod_perl for use with ActiveState Perl and Strawberry - you can find them here: http://people.apache.org/~stevehay/ Just download and unzip and it works. P.S. I do not have a C compiler on my laptop, and I'd prefer to stick to Windows XP as long as it works. both ActiveState and Strawberry come with dmake nowadays! -- Thanks, Mike. That did it. Works like a charm. I guess that this could be a useful tip to add to the on-line mod_perl documentation for the Win32 installation, but I have no idea how one goes about this. André
Windows XP, Apache, perl 5.16, mod_perl
Hi guys. We generally work on Linux Debian systems, and install Apache httpd, perl and mod_perl from the package manager, and it works great. However, for some cases - like my Windows XP development laptop - I would like a local copy of this all, to develop and test new software. (Also because I need to support customers under Windows). I used to install a recent version of perl from ActiveState and then a mod_perl ppm from the UWinnipeg repository, but that option doesn't seem to exist anymore. Could you recommend one "integrated" solution for this, in terms of Apache httpd 2.2.x, and a recent perl version ? Like, something which works without having to spend a week resolving dependencies and incompatibilities ? Thanks P.S. I do not have a C compiler on my laptop, and I'd prefer to stick to Windows XP as long as it works.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
demerphq wrote: On 28 February 2013 21:12, André Warnier wrote: I am ranting, and I know it. But the basic fact is that " ", in 99% of programming languages I doubt it, considering all the major languages I know of use a "," to separate arguments. And if you are in a programming language then the filename will be stored in a variable, so you generally wont care if it contains spaces, or whatever. and OS shells Here it is maybe true. is a meta-character that normally acts as a separator between arguments, keywords, parameters, whatever. So electing to allow it in paths and filenames was a bad decision, which has cost so far millions of unproductive hours to be spent, and will cost many more millions before a reasonable parade is found. If you accept arbitrary sets of filenames and expect to feed them as arguments to something like a shell without managing issues like them having spaces in them then you are opening yourself up to way worse issues than them having spaces in them. Whats to stop them giving you a filename that is actually a command, or a redirect, or whatever? You do not have to convince us, I think that we all know this already. You may want to read http://perldoc.perl.org/perlsec.html#SECURITY-MECHANISMS-AND-CONCERNS if you haven't yet done so. It may give you some additional ideas about things to watch for. Or take your latest perl program, and remove all spaces from it, just for a laugh. But I believe that you are missing the point of this whole disgression entirely, and you may want to re-read it from the beginning, and take it for what it is. LOL.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
Randolf Richardson wrote: alexander.elg...@external.t-systems.com wrote: ... I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. Apple's older pre-Unix-backended MacOS models allowed "/" characters in filenames. But I agree, it is an annoyance it should be forbidden. ;) The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. Heheh. The makers of the Commodore 64 are off-limits because 8-bit gaming was practically revolutionized by it. (Yes, that's right, spaces were permitted in filenames on the Commodore 64, so this silliness came about before the PC and the Mac gained popularity.) Thanks for this tidbit. I really thought that some marketing guru at Microsoft was the original culprit. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler. That really was a ridiculous decision, and lately they've taken it to new heights by adding yet another "C:/Program Files (x86)/" path that contains two spaces and parenthesis. Given that "C:/Documents and Settings/" has since been changed to "C:/Users/" I'll take that as a sign of hope that a "C:/Programs/" directory may be on the horizon (but I'm not holding my breath). I wouldn't either, not without a couple of scuba-diving breathing bottles. If only because - on a Spanish Windows PC, the directory is called "C:\Archivos de Programas" - on a Portuguese Windows PC, it is called "C:\Arquivos de Programas" - on a greek Windows PC, it is "Αρχεία Εφαρμογών" - on a German Windows PC, it is called "C:\Programme" (that must definitely be an oversight) (And yes, I know that one can sometimes use %ProgramFiles% instead, but why would one have to do that ? Doesn't anyone who ever used a computer understand the word "programs" ?) In truth, Microsoft is not alone there. An Apache httpd by default installs under a (created) directory named "Apache Software Foundation" of all things. One would think that /they/ at least would know better. But no. Why make it simple when annoying will do ? Gimme C:\Perl anytime. I am ranting, and I know it. But the basic fact is that " ", in 99% of programming languages and OS shells, is a meta-character that normally acts as a separator between arguments, keywords, parameters, whatever. So electing to allow it in paths and filenames was a bad decision, which has cost so far millions of unproductive hours to be spent, and will cost many more millions before a reasonable parade is found. Whether it has been lost by good_programmers or bad_programmers is a moot point; there are only so many star programmers around, and the others need a job too. If the time lost because of that original mistake had been put to productive use instead, we might today have an environment where we just tell our computer in general terms what needs to be done, and it produces a first draft of the code to do it. Or we might have a HTTP 2.0 where the default character set is Unicode and UTF-8 is the default encoding. But I guess that this is another subject for another rant sometime.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
David Booth wrote: On 02/28/2013 09:32 AM, Torsten Förtsch wrote: On 02/28/2013 03:14 PM, demerphq wrote: A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. Yes, right next door to another place in hell that is reserved for people who put spaces and other unprintables in filenames. :-) Which is probably why it is called hell, after all.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
demerphq wrote: On 28 February 2013 13:29, André Warnier wrote: alexander.elg...@external.t-systems.com wrote: ... I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. But I agree, it is an annoyance it should be forbidden. ;) The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler. What a stupid thing to say. My comment was meant as light and humorous. I am sorry that it was misunderstood, and sorry that you feel like starting to call names. Relax. You can use those things on pretty much every file system and OS. 1) not without quoting them, you can't. Which is the whole point. and 2) which does not mean that it was a good idea to start with, nor that it is a good idea to keep going along with it. The layout of the keys on the computer keyboard on which you are now typing was designed originally for mechanical writing machines, and its purpose was to slow down typing, so that the levers would not cross eachother. Does it still make sense ? no. Do we keep on using them ? yes. Ever since your grandmother started using a computer and thought it was pretty darn stupid for young whippersnappers like yourself to tell her that she couldnt name a file "good recipies". Sir, you flatter me. Being called a young whippersnapper hasn't happened to me in a long, long time. My grandmother - peace to her soul - never even heard about computers. But had she used them, she could also not have saved a file named "bills/to-pay", nor a file named "good recipes" (she could spell) written in the special reddish ink color that she used in her cookbooks. And had she wanted to call me on the telephone, she would have had to dial a number composed of the digits 0-9, she could not have just typed my name. A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. If that is their only sin, then I'd assume that this special place would be rather nice, relatively speaking. And I'd happily join them, because I freely admit that I have made that same mistake several times (in my youth of course). But it is probably pretty crowded. Let me put this another way. Would you be willing to have your salary docked, until it has paid for the time lost over the last 20 years, due to mistakes inadvertently made by programmers with 10 years or more of experience, in failing to properly quoting paths or filenames because they could have spaces in them ? Or to put in yet another way : would you publically declare here that you have *never* yourself made such a mistake ? It has also been a while since I have personally programmed something without taking this fact into account. Which does not mean that I like it. And I have seen several generations of programmers working for me, who are still making that same mistake. The point is that one must take it into account, and has to add extra programming steps *every time* to take this into account. And it did not necessarily have to be so. If "\0" and "/" or "\" and "<" and ">" and "|" and "&" are disallowed in filenames on most systems, I fail to see how disallowing spaces would be such a dramatic drawback. But I can easily imagine how disallowing spaces in filenames would save the world many thousand work hours every year. Would you pretend the opposite ? Like the keyboards, it can probably not be changed anymore, so we are stuck with it. But I often think nostalgically about what would have happened (or not happened) if that original designer had just said "hey, let's not allow spaces in paths and filenames; they can use underlines instead".
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
alexander.elg...@external.t-systems.com wrote: ... I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. But I agree, it is an annoyance it should be forbidden. ;) The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler.
Re: Question on how execution order of Mod_Persl
Timothy Gallagher wrote:
Hello all,
I have a question for you that I am needed some help/guidance on. I am not
sure if this is a question for Apache, perl or mod_perl, I believe this is the
correct place to ask. I am building a reverse proxy server that authenticates
a user via the client SSL certificate that is presented to Apache.
When a person connects to https:// alpha.dev.home.com/ssl, they are requested
to present a client SSL cert to the server. Using Mod_Perl, I then get the
client certificate information and do some internal processing to verify the
user. If the user is good, I want to then continue the request by acting as a
reverse proxy servers for internal apache servers.
I have all these processes working except not in the correct order. Here is
the order that the items are happening.
A user will connect to https:// alpha.dev.home.com/ssl. The user is presented
with a request for a client certificate. When the user presents the
certificate, they are then allowed access to the backend (private apache web
server). At the same time, mod_perl is processing their client SSL certificate.
Am I able to have the dictate the order of how a request in apache with
mod_perl I processed meaning
1. Request comes in
2. Customer needs to present a client SSL certificate
3. Mod_perl takes the client certificate information and processes the
information for authentication
4. Depending the outcome of the authentication process, allow the session
to continue or drop the connection.
Here is the code that I am using for testing
-[Begin Apache Config]-
# Get the required enviorment
PerlRequire /opt/perlEngine/startup.pl
# SSL Requirements
SSLEngine on
SSLProtocol +SSLv3 +TLSv1
SSLCertificateFile
/opt/certs/server/al...@danati.home.com-cert.pem
SSLCertificateKeyFile
/opt/certs/server/al...@danati.home.com-key.pem
SSLCACertificateFile
/opt/certs/ca/BlackSands-Refereence-CA-cacert.pem
SSLVerifyClient require
SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth
SetHandler perl-script
PerlResponseHandler MyTest::SSLAuth
ProxyRequests off
ProxyPass /ssl http://10.10.10.100
ProxyPassReverse /ssl http://10.10.10.100
-[End Apache Config]-
-[Begin MyTest::SSLAuth ]-
package MyTest::SSLAuth;
#use Apache2::ModSSL;
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Digest::SHA qw(sha256_hex);
use Apache2::Const -compile => qw(OK);
use Data::Dumper;
sub handler {
my $r = shift;
$r->content_type('text/plain');
my $c=$r->connection;
my $cert = $r->subprocess_env('SSL_CLIENT_CERT');
my $serial = $r->subprocess_env('SSL_CLIENT_M_SERIAL');
my $dn = $r->subprocess_env('SSL_CLIENT_S_DN');
my $sig = $r->subprocess_env('SSL_CLIENT_A_SIG');
if($sig != 89765479){
DoSomthing ..
}
return Apache::OK;
}
1;
-[End MyTest::SSLAuth ]-
Hi.
I believe that you may have the same kind of issue that I was having back in
December 2012.
Check the archives of this list, for a thread entitled "setHandler question".
Doing authentication and then proxying is a bit tricky.
The good news is that it works in the end, so your scheme is possible.
Re: alias command in modperl environment
Feng He wrote: Hello, ServerAdmin x...@yyy.com ServerName example.com PerlModule Apache::DBI PerlPostConfigRequire /path/to/startup.pl SetHandler modperl PerlResponseHandler Handler1 SetHandler modperl PerlResponseHandler Handler2 Alias /zzz/ "/var/www/zzz/" Options FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/cdn.access.log combined I put some static files under /var/www/zzz/. When accessing these static files, I got 403 error. Can't alias command work for this case? I believe that you have the following problem : What you specify in the "", by default, is inherited by all "sub-Locations" of "/", so for example the location "/zzz/" inherits the "SetHandler modperl" from the location "/". I don't remember the exact syntax, but try to add the following : SetHandler default (or maybe it is "none") .. (other directives) Generally, I try to avoid setting a special handler or other special rules for the Location "/", for precisely that kind of reason : you find that you then need to override these defaults in every sub-directory of your setup.
Re: setHandler question
Rafael Caceres wrote: ... What you want works for me when reverse proxying to Tomcat or another Apache by adding a require valid-user inside the LocationMatch Thanks for your interest. That would indeed work if my authentication sub returned an "auth required" when the request is not authenticated. But right now it doesn't. Instead, it returns OK, but (tries to) set up a special ResponseHandler to return a login page. That is what failed previously, as Apache didn't seem to care and mod_proxy was still responding to the request. But that is now solved, and it works as expected, see previous messages in thread. André
Re: setHandler question
André Warnier wrote:
Torsten Förtsch wrote:
On 12/15/2012 01:30 PM, André Warnier wrote:
And somehow the $r->add_config() looks a bit like a roundabout way of
achieving what I want. If I can, kind of, "stuff" an additional
SetHandler configuration directive into the Apache configuration for my
request, telling Apache "now do as if the contained a
SetHandler directive", then why does the simpler $r->setHandler() not
work ?
Perhaps that was the reason for ->add_config instead of ->handler. The
former sets the handler at the point in the request cycle when
SetHandler works, which I think is fixup. The latter acts at the point
of the call.
The point here is that modperl's PerlFixupHandler is registered with
APR_HOOK_REALLY_FIRST meaning it is called before (almost) all other
handlers. So, even if you use ->handler to set the handler to modperl
another module may decide to override your decision.
There is another glitch with mod_proxy here. A normal response handler
checks the content of ->handler to see if it is responsible to generate
the response. Not so mod_proxy. It relies on ->proxyreq:
In fact, where other modules do something like this to decide if they
are to generate the response:
if(strcmp(r->handler, CGI_MAGIC_TYPE) &&
strcmp(r->handler, "cgi-script"))
return DECLINED;
mod_proxy does this:
/* is this for us? */
if (!r->proxyreq || !r->filename ||
strncmp(r->filename, "proxy:", 6) != 0)
return DECLINED;
I think what you want to do is to reconfigure a request previously set
up to be handled by mod_proxy, right? So, in that case you have to
either reset $r->proxyreq to 0 or reset $r->filename to NULL or to
change $r->filename to not start with "proxy:".
YES, resetting $r->filename() does it.
Just for the sake of it, I forced it to the URL of my login page(*), and
it doesn't proxy anymore.
Thanks.
Now I'll study the info above, to really try to understand what's going on.
(*) which I know is wrong, but since I retrieve the login page myself in
the ResponseHandler, I figured it didn't matter.
I also tried the following sequence, and it works just as well :
$r->proxyreq(Apache2::Const::PROXYREQ_NONE);
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_send_login_form);
And I also tried :
my $dest = $r->filename();
$dest =~ s/^proxy://;
$r->filename($dest);
# $r->proxyreq(Apache2::Const::PROXYREQ_NONE);
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_send_login_form);
and it also works (with or without the commented $r->proxyreq)
I am in the meantime discussing the same thing with Rainer Jung (developer of the mod_jk
Apache/Tomcat connector module), because in terms of functionality, mod_jk is similar to
mod_proxy. I hope to be able to write some code in the end which covers all cases at once.
And anyway this is fun. Doing things with mod_perl provides a lot of insights in terms of
how Apache httpd works.
Thanks very much for the help.
André
Apache2 constants syntax question
Hi. I suppose that this is a bit academical, but I'm wondering anyway. In Apache2::Const, there are a number of constants member of the ":common" import group, which are (presumably) the same as their near equivalent in the ":http" import group. For example : Apache2::Const::FORBIDDEN ~ Apache2::Const::HTTP_FORBIDDEN etc.. Which ones should I use ? Is there a difference ? If not, what was the idea in defining some of them twice with a different name ?
Re: setHandler question
Torsten Förtsch wrote: On 12/15/2012 01:30 PM, André Warnier wrote: And somehow the $r->add_config() looks a bit like a roundabout way of achieving what I want. If I can, kind of, "stuff" an additional SetHandler configuration directive into the Apache configuration for my request, telling Apache "now do as if the contained a SetHandler directive", then why does the simpler $r->setHandler() not work ? Perhaps that was the reason for ->add_config instead of ->handler. The former sets the handler at the point in the request cycle when SetHandler works, which I think is fixup. The latter acts at the point of the call. The point here is that modperl's PerlFixupHandler is registered with APR_HOOK_REALLY_FIRST meaning it is called before (almost) all other handlers. So, even if you use ->handler to set the handler to modperl another module may decide to override your decision. There is another glitch with mod_proxy here. A normal response handler checks the content of ->handler to see if it is responsible to generate the response. Not so mod_proxy. It relies on ->proxyreq: In fact, where other modules do something like this to decide if they are to generate the response: if(strcmp(r->handler, CGI_MAGIC_TYPE) && strcmp(r->handler, "cgi-script")) return DECLINED; mod_proxy does this: /* is this for us? */ if (!r->proxyreq || !r->filename || strncmp(r->filename, "proxy:", 6) != 0) return DECLINED; I think what you want to do is to reconfigure a request previously set up to be handled by mod_proxy, right? So, in that case you have to either reset $r->proxyreq to 0 or reset $r->filename to NULL or to change $r->filename to not start with "proxy:". YES, resetting $r->filename() does it. Just for the sake of it, I forced it to the URL of my login page(*), and it doesn't proxy anymore. Thanks. Now I'll study the info above, to really try to understand what's going on. (*) which I know is wrong, but since I retrieve the login page myself in the ResponseHandler, I figured it didn't matter.
Re: setHandler question
Torsten Förtsch wrote:
On 12/14/2012 02:52 PM, André Warnier wrote:
Or am I totally off-track here ?
I think yes, you are confused by the similarity of "finfo" and
"OR_FILEINFO".
Yes, I was. Thanks for setting me right.
The finfo part of $r is simply a data structure that represents the
metadata of a file on the filesystem such as modification dates, access
rights, the size and whether it is a regular file, directory, socket or
something else.
A standard request for a static file in Apache works as follows. In the
MapToStorage phase the request URI is mapped to a file (or directory) on
the filesystem (by means of DocumentRoot, Alias and the like). Then also
in the MapToStorage phase Apache performs a stat(2) call on the resolved
file name. The result is stored in $r->finfo.
Ok. Then, in my case I have
PerlAuthenHandler SLC->authenticate
PerlAuthzHandler SLC->authorize
PerlSetVar SLC_login_page "/public/login.html"
...
ProxyPassMatch http://localhost:8800/$1
"/IIS_app/" does not map to anything on the filesystem.
I guess then that $r->finfo should not contain anything, or at least nothing related to a
disk file. And neither $r->filename();
Then in the response phase the information stored in finfo is used to
set up the Content-Length header as well as the cache control headers
like Etag and Last-Modified.
So nothing here that is relevant, as these headers would normally be generated
by IIS.
OR_FILEINFO on the other hand is simply a flag that represents the
"FileInfo" flag in the "AllowOverride" directive:
http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride
Modperl's $r->add_config acts more or less like a .htaccess file. In
this context the "SetHandler" directive needs "AllowOverride FileInfo"
to be in effect. See
http://httpd.apache.org/docs/2.2/mod/core.html#sethandler
Unlike a .htaccess file, $r->add_config expects the override bits as the
next parameter after the list of configuration directives.
So, to be able to set the handler by means of
$r->add_config(['SetHandler ...'])
you have to pass along a set of override bits that includes OR_FILEINFO.
That means for example
$r->add_config(['SetHandler ...'], OR_FILEINFO)
or even
$r->add_config(['SetHandler ...'], ~0)
since ~0 is an integer with all bits set.
I can't remember why I hinted at $r->add_config instead of
$r->handler('newhandler') at the time of the first discussion. Perhaps
there was a reason (like the wrong request phase), perhaps I had a blackout.
Perhaps. But you are forgiven, since I think that it was with the best of
intentions anyway.
My basic question is that I am setting
$r->handler('modperl');
in the PerlAuthenHandler above, and neither Apache nor mod_perl complain. But it does not
stop Apache from proxying the call anyway.
Even if (as per one of your earlier suggestions), I do (or repeat) this
$r->handler('modperl'); in a Fixup handler.
Why is that ?
Does mod_proxy somehow have still some "priority" as compared to the mod_perl
handler ?
Does mod_proxy do something earlier in the cycle that causes the $r->handler() to
(silently) have no effect later ?
I hope you understand now that "OR_FILEINFO" and "finfo" are completely
unrelated things. The only thing they have in common is a certain
similarity in their names.
Yes, I understand that now. My confusion came from imagining that the MapToStorage phase
(subverted ny mod_proxy) might put something in the $r->finfo, that would cause the effect
later.
I know that I can do this via either an ErrorDocument, or via the call to
$r->add_config(['SetHandler ...'], OR_FILEINFO).
But my current code is not really suited to do it via an ErrorDocument.
And somehow the $r->add_config() looks a bit like a roundabout way of achieving what I
want. If I can, kind of, "stuff" an additional SetHandler configuration directive into
the Apache configuration for my request, telling Apache "now do as if the
contained a SetHandler directive", then why does the simpler $r->setHandler() not work ?
Re: setHandler question
Ryan Gies wrote:
On 12/14/2012 8:52 AM, André Warnier wrote:
I suppose that in the end I will want to do something like this :
my $finfo = $r->finfo();
# do something to $finfo to set the flag
$r->finfo($finfo);
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_my_response_handler);
but how do I "do something to $finfo" ?
Or am I totally off-track here ?
TIA
For what it's worth, I have consistent success in using $r->finfo to
tell Apache the final destination. In the case that $you_want_to_hook
(below) is false, Apache will also serve the intended file. The timing
used is:
PerlMapToStorageHandler
$r->filename($path); # where $path is an absolute file-system path
$r->finfo(APR::Finfo::stat($path, APR::Const::FINFO_NORM, $r->pool));
return Apache2::Const::OK;
PerlFixupHandler
if ($you_want_to_hook) {
$r->push_handlers(PerlResponseHandler => \&_response_handler);
$r->handler('modperl');
return Apache2::Const::OK;
}
Let me explain better what I am looking for :
PerlAuthenHandler SLC->authenticate
PerlAuthzHandler SLC->authorize
PerlSetVar SLC_login_page "/public/login.html"
...
ProxyPassMatch http://localhost:8800/$1
In other words,
- Apache+mod_perl is acting as a reverse proxy for an application running under IIS on the
same server
- but this IIS application requires a special HTTP header to authenticate the
user
- In the Location above, the PerlAuthenHandler checks if the user is
authenticated.
- If yes, it adds the required HTTP header to the request, and then a few steps later
the proxying happens to IIS, and that's fine.
- If not, it sends back a login page.
What I want to do refers to the "sends back a login page".
In case the user is not authenticated, I do /not/ want Apache to proxy the call
to IIS.
I want to reset the response handler so that it is no longer mod_proxy, but mod_perl, and
my own PerlResponseHandler (which sends back the login page "/public/login.html", after
munching on it).
But what happens is that the proxying runs anyway, and the request ends up in IIS, but
without the authentication header.
That's what I want to avoid.
In the PerlAuthenHandler, I already do this :
if ($not_authenticated)
{
$r->handler('modperl'); # (1)
$r->set_handlers(PerlResponseHandler => \&_my_send_login_handler); # (2)
$r->set_handlers(PerlFixupHandler => sub { $_[0]->handler('modperl') } ); #
(3)
return Apache2::Const::OK;
}
But that is apparently not enough. It is still (later) proxying the request to
IIS.
So it is apparently ignoring the line
$r->handler('modperl'); # (1)
What am I missing ? (as another way of phrasing the initial question)
I am led to believe that it has to do with the "map-to-storage" phase, which has already
happened by the time the PerlAuthenHandler runs, and that in order to completely override
the mod_proxy response handler, I need to set/reset some flag(s).
I'd like (if possible) to do that "dynamically" in the PerlAuthenHandler, without having
to configure an extra PerlMapToStorageHandler in my configuration for that Location.
(In the above, (1) and (3) are probably the same thing, with (3) happening later and
having maybe a better chance. But it's still not working.
Would these 2 lines :
> $r->filename($path); # where $path is an absolute file-system path
> $r->finfo(APR::Finfo::stat($path, APR::Const::FINFO_NORM, $r->pool));
added to the above current code, do the trick ?
setHandler question
Hi.
Quite a while ago (2008), this discussion on the list :
http://marc.info/?l=apache-modperl&m=122399752819709&w=2
was about how to, within a PerlAuthenHandler, override the ResponseHandler which would
normally kick in later in the cycle, and force it to be mod_perl and a specific (other)
PerlresponseHandler.
The general idea is like :
if (some_condition) {
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_my_response_handler);
}
or even :
$r->set_handlers(PerlResponseHandler => \&_my_response_handler);
$r->set_handlers(PerlFixupHandler => sub { $_[0]->handler('modperl') } );
and generally speaking it works.
Only, sometimes it doesn't, and Apache proceeds to use the previously-configured response
handler no matter what.
Then there was a hint that, in addition to the above, one might need to also set or clear
something in the $r->finfo structure, to (as I, with my limited knowledge understand it)
tell Apache that we really know what we are doing, and really want to override what it
already knows about the final destination.
This "thing" to set in the $r->finfo() being Apache2::Const::OR_FILEINFO or
thereabouts.
And an example was even given in the thread, as :
$r->add_config(['SetHandler ...'], Apache2::Const::OR_FILEINFO)
Only, here I have already set the Handler, and I would merely want to try just to set the
above flag.
So how would I do that ?
I do not see a way to pass this argument in $r->handler().
I see in the doc this :
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_finfo_
but I do not really understand the example given.
I suppose that in the end I will want to do something like this :
my $finfo = $r->finfo();
# do something to $finfo to set the flag
$r->finfo($finfo);
$r->handler('modperl');
$r->set_handlers(PerlResponseHandler => \&_my_response_handler);
but how do I "do something to $finfo" ?
Or am I totally off-track here ?
TIA
Re: Soulution maybe? for Re: Connection aborted was ModPerl::Util::exit: (120000) at Carp.pm line 590
Dave Morgan wrote:
Hi All,
Short summary, original problem
ModPerl::Util::exit: (12) exit was called at
/usr/share/perl5/CGI/Carp.pm line 590
after hacking out Carp
"Software caused connection abort." at 3 different places in our
code
The code in question is essentially
print $CGI->header( $header_info_ref );
print $response; #fails here
This was happening a minimum of 150 to 200 times a day. Changed the code to
print $CGI->header( $header_info_ref );
eval{print $response;}; #wrap failure
print STDERR $@ . "\n\n";
This will print blank lines if there was no error. Maybe you should do this :
> print STDERR $@ . "\n\n" if $@;
However, it seems $@ is always empty. So, I no longer have connection
aborted errors
You still have the errors. You just don't see them in the logs anymore.
But that is probably a benefit, because there is nothing much you can do about
them anyway.
Most of the time, they happen because the user has already clicked somewhere else, without
waiting to receive the full answer from the server (or just closed the browser window).
So your application is trying to write data to a socket that is already closed at the
client side.
Because of all the buffering involved, that condition does not immediately reflect all the
way upstream. That's probably why the headers still go out ok (there is room in the
buffers), but the whole response doesn't fit, and that's when the error percolates to your
script and boom.
Now I know I'm easily confused but I don't understand :)
Hope that now you understand a bit more. ;-)
However, as it
does appear
I have fixed the issue I am quite happy. I just wish I knew why it works.
Discovered along the way was do not write anything between the http
header and the
html DOC_TYPE as anything Microsoft based other than IE 10 will not
display css floats properly.
Not to absolve Microsoft of all the inconsistencies in their browsers, but isn't the
DOCTYPE supposed to be the first line of a document, if there is a DOCTYPE ?
If you print anything before, knowing the MS-browser ways, they probably try to "sniff"
the content themselves, no matter what the server sent as headers.
And they probably get it wrong, which means that they probably determine this to be the
wrong version of html, which means that they probably reject tags that shouldn't be in the
according to their wrongly-determined html version's DTD.
Re: Charset in response
André Warnier wrote:
André Warnier wrote:
Torsten Förtsch wrote:
On 11/29/2012 10:37 AM, André Warnier wrote:
When I say that it doesn't work, I mean in fact :
- the "Content-Type" response header sent by the server is properly set
according to what I do above (as verified in a browser plugin)
- but if what I print contains "accented" characters, they are not
being
encoded properly
So, do I need to set something else so that the $r->print(string) will
output "string" properly ?
Background :
My PerlResponseHandler reads a html file from disk, replaces some
strings into it, and sends the result out via $r->print.
The source html file can be encoded in iso-8859-1 or UTF-8, and it
contains a proper declaration of the charset under which it is really
encoded :
or
To read the file, I first open it "raw", read a few lines, checking for
the above tag. If found, I note the charset (say in $charset),
close the file, and re-open it as
open(my $fh,"<:encoding($charset)", $file);
(note : if $charset is "UTF-8", then the open becomes
open(my $fh,'<:utf8', $file);)
So, you convert the octet stream into a character stream when you read
the file. You have to do the reverse when you write it.
I have to, to be able to be consistent in my string-replacement logic.
$r->print(Encode::encode $encoding, $string);
Modperl usually uses perlio. So, perl-script handler should be able to
push an encoding layer on top of the :Apache2 layer.
binmode STDOUT, ':encoding(...)'
But I haven't tried this yet.
Now, that I think of it, perhaps even the following would work
open my $fh, '>:Apache2:encoding(...)', $r;
print $fh $string;
If it does not work it would be good to make it so.
I'll try the above and let you know.
I guess that if I can do
open my $fh, '>:Apache2:encoding(...)', $r;
then $r, under the hood, must be some kind of filehandle too.
And then I could just do
binmode($r,":encoding($charset)");
but then, this being mod_perl, it may leave it that way and have
unexpected side-effects somewhere else..
Results :
1) using : open my $fh, '>:Apache2:encoding(...)', $r;
(Note: I can't find Apache2::encoding anywhere. Was that a typo ?)
$logger->warn("$pfx: reading form using encoding [$enc]") if $Debug>1;
...
my $response_fh;
unless (open ($response_fh,">:$enc",$r)) {
$logger->error("$pfx Cannot open \$r : $?");
return Apache2::Const::SERVER_ERROR;
}
brings server error and logs :
[Thu Nov 29 15:48:42 2012] [warn] [client 192.168.245.129]
AM::SendForm::response: reading form using encoding [encoding(iso-8859-1)]
[Thu Nov 29 15:48:42 2012] [error] [client 192.168.245.129]
AM::SendForm::response Cannot open $r : 0
2) using : binmode STDOUT, ':encoding(...)'
$logger->warn("$pfx: reading form using encoding [$enc]") if $Debug>1;
...
binmode(STDOUT,":$enc");
...
$logger->warn(" input line is [$line], utf8 flag : " .
(Encode::is_utf8($line) ? "y" : "n"));
...
$r->print($line);
...
does not bring server error and outputs the page, but apparently has no
effect (characters are still wrong) :
[Thu Nov 29 15:55:52 2012] [warn] [client 192.168.245.129] input line
is [\t\t\t\tid="ANSPR"> m\xc3\xa4nnlich\n], utf8 flag : y
(in the response also)
3) same as (2), but using simple "print $line;" instead of
"$r->print($line);"
That is very bizarre. It runs through the code for many lines. It
still prints the one "Männlich" line wrong (in the log and in the html
output as well):
client 192.168.245.129] input line is [\t\t\t\ttype="radio" value="m" id="ANSPR"> m\xc3\xa4nnlich\n], utf8 flag : y
but now in addition, it crashes a few lines further with a server error
and this in the log :
[Thu Nov 29 16:01:45 2012] [warn] [client 192.168.245.129] input line
is [ \n], utf8 flag : y
[Thu Nov 29 16:01:45 2012] [error] [client 192.168.245.129] "\\x{4bae}"
does not map to iso-8859-1 at
/usr/local/lib/apache2/perllib/AM/SendForm.pm line 203, <$form_fh> line
101.\n
The line 101 of the input form is as shown in the log just before the
error :
and the next line is a simple
I have examined the form with a UTF-8 capable editor, and I see no extra
bizarre characters anywhere near. I have no idea where this ""\\x{4bae}"
could be coming from.
4) trying : $r->print(Encode::encode $encoding, $string);
as : $r->print(Encode::encode($charset,$line));
Bingo !
It still prints in the log :
[Thu Nov 29 16:21:42 2012] [warn] [client 192.168.245.129] input line
is [\t\t\t\tid="ANSPR"> m\xc3\xa4nnlich\n], utf8 flag : y
But it
Re: Charset in response
André Warnier wrote:
Torsten Förtsch wrote:
On 11/29/2012 10:37 AM, André Warnier wrote:
When I say that it doesn't work, I mean in fact :
- the "Content-Type" response header sent by the server is properly set
according to what I do above (as verified in a browser plugin)
- but if what I print contains "accented" characters, they are not being
encoded properly
So, do I need to set something else so that the $r->print(string) will
output "string" properly ?
Background :
My PerlResponseHandler reads a html file from disk, replaces some
strings into it, and sends the result out via $r->print.
The source html file can be encoded in iso-8859-1 or UTF-8, and it
contains a proper declaration of the charset under which it is really
encoded :
or
To read the file, I first open it "raw", read a few lines, checking for
the above tag. If found, I note the charset (say in $charset),
close the file, and re-open it as
open(my $fh,"<:encoding($charset)", $file);
(note : if $charset is "UTF-8", then the open becomes
open(my $fh,'<:utf8', $file);)
So, you convert the octet stream into a character stream when you read
the file. You have to do the reverse when you write it.
I have to, to be able to be consistent in my string-replacement logic.
$r->print(Encode::encode $encoding, $string);
Modperl usually uses perlio. So, perl-script handler should be able to
push an encoding layer on top of the :Apache2 layer.
binmode STDOUT, ':encoding(...)'
But I haven't tried this yet.
Now, that I think of it, perhaps even the following would work
open my $fh, '>:Apache2:encoding(...)', $r;
print $fh $string;
If it does not work it would be good to make it so.
I'll try the above and let you know.
I guess that if I can do
open my $fh, '>:Apache2:encoding(...)', $r;
then $r, under the hood, must be some kind of filehandle too.
And then I could just do
binmode($r,":encoding($charset)");
but then, this being mod_perl, it may leave it that way and have
unexpected side-effects somewhere else..
Results :
1) using : open my $fh, '>:Apache2:encoding(...)', $r;
(Note: I can't find Apache2::encoding anywhere. Was that a typo ?)
$logger->warn("$pfx: reading form using encoding [$enc]") if $Debug>1;
...
my $response_fh;
unless (open ($response_fh,">:$enc",$r)) {
$logger->error("$pfx Cannot open \$r : $?");
return Apache2::Const::SERVER_ERROR;
}
brings server error and logs :
[Thu Nov 29 15:48:42 2012] [warn] [client 192.168.245.129] AM::SendForm::response: reading
form using encoding [encoding(iso-8859-1)]
[Thu Nov 29 15:48:42 2012] [error] [client 192.168.245.129] AM::SendForm::response Cannot
open $r : 0
2) using : binmode STDOUT, ':encoding(...)'
$logger->warn("$pfx: reading form using encoding [$enc]") if $Debug>1;
...
binmode(STDOUT,":$enc");
...
$logger->warn(" input line is [$line], utf8 flag : " . (Encode::is_utf8($line) ? "y" :
"n"));
...
$r->print($line);
...
does not bring server error and outputs the page, but apparently has no effect (characters
are still wrong) :
[Thu Nov 29 15:55:52 2012] [warn] [client 192.168.245.129] input line is [\t\t\t\tname="ANSPR" type="radio" value="m" id="ANSPR"> m\xc3\xa4nnlich\n], utf8 flag : y
(in the response also)
3) same as (2), but using simple "print $line;" instead of "$r->print($line);"
That is very bizarre. It runs through the code for many lines. It still prints the one
"Männlich" line wrong (in the log and in the html output as well):
client 192.168.245.129] input line is [\t\t\t\tid="ANSPR"> m\xc3\xa4nnlich\n], utf8 flag : y
but now in addition, it crashes a few lines further with a server error and
this in the log :
[Thu Nov 29 16:01:45 2012] [warn] [client 192.168.245.129] input line is
[ \n], utf8 flag : y
[Thu Nov 29 16:01:45 2012] [error] [client 192.168.245.129] "\\x{4bae}" does not map to
iso-8859-1 at /usr/local/lib/apache2/perllib/AM/SendForm.pm line 203, <$form_fh> line 101.\n
The line 101 of the input form is as shown in the log just before the error :
and the next line is a simple
I have examined the form with a UTF-8 capable editor, and I see no extra bizarre
characters anywhere near. I have no idea where this ""\\x{4bae}" could be coming from.
4) trying : $r->print(Encode::encode $encoding, $string);
as : $r->print(Encode::encode($charset,$line));
Bingo !
It still prints in the log :
[Thu Nov 29 16:21:42 2012] [warn] [client 192.168.245.129] input line is [\t\t\t\tname="ANSPR" type="rad
Re: Charset in response
Torsten Förtsch wrote: On 11/29/2012 10:37 AM, André Warnier wrote: When I say that it doesn't work, I mean in fact : - the "Content-Type" response header sent by the server is properly set according to what I do above (as verified in a browser plugin) - but if what I print contains "accented" characters, they are not being encoded properly So, do I need to set something else so that the $r->print(string) will output "string" properly ? Background : My PerlResponseHandler reads a html file from disk, replaces some strings into it, and sends the result out via $r->print. The source html file can be encoded in iso-8859-1 or UTF-8, and it contains a proper declaration of the charset under which it is really encoded : or To read the file, I first open it "raw", read a few lines, checking for the above tag. If found, I note the charset (say in $charset), close the file, and re-open it as open(my $fh,"<:encoding($charset)", $file); (note : if $charset is "UTF-8", then the open becomes open(my $fh,'<:utf8', $file);) So, you convert the octet stream into a character stream when you read the file. You have to do the reverse when you write it. I have to, to be able to be consistent in my string-replacement logic. $r->print(Encode::encode $encoding, $string); Modperl usually uses perlio. So, perl-script handler should be able to push an encoding layer on top of the :Apache2 layer. binmode STDOUT, ':encoding(...)' But I haven't tried this yet. Now, that I think of it, perhaps even the following would work open my $fh, '>:Apache2:encoding(...)', $r; print $fh $string; If it does not work it would be good to make it so. I'll try the above and let you know. I guess that if I can do open my $fh, '>:Apache2:encoding(...)', $r; then $r, under the hood, must be some kind of filehandle too. And then I could just do binmode($r,":encoding($charset)"); but then, this being mod_perl, it may leave it that way and have unexpected side-effects somewhere else..
Re: Charset in response
Addendum at end.
André Warnier wrote:
Hi.
I have a problem with a PerlResponseHandler, regarding the character set
used in the response to a request.
Basically, the question is : how to I set the character set properly for
the "handle" used in
$r->print("string") ?
(where string can be "äéèöü" for example)
Neither of the following (which I do before starting to print output)
seems to work :
$r->headers_out->unset('content-type');
$r->headers_out->set('content-type','text/html;charset=');
or
$r->content_type('text/html;charset=');
When I say that it doesn't work, I mean in fact :
- the "Content-Type" response header sent by the server is properly set
according to what I do above (as verified in a browser plugin)
- but if what I print contains "accented" characters, they are not being
encoded properly
So, do I need to set something else so that the $r->print(string) will
output "string" properly ?
Background :
My PerlResponseHandler reads a html file from disk, replaces some
strings into it, and sends the result out via $r->print.
The source html file can be encoded in iso-8859-1 or UTF-8, and it
contains a proper declaration of the charset under which it is really
encoded :
or
To read the file, I first open it "raw", read a few lines, checking for
the above tag. If found, I note the charset (say in $charset),
close the file, and re-open it as
open(my $fh,"<:encoding($charset)", $file);
(note : if $charset is "UTF-8", then the open becomes
open(my $fh,'<:utf8', $file);)
I also at that point set the response charset by one of the means above.
Then I read the file line by line, substituting some strings in the
line, and print out the line via
$r->print($line);
etc..
My problem is that, if the input file is for example iso-8859-1 and
contains the word "Männer", the output comes out as "M(A tilde)(some
byte)nner" (the bytes corresponding to the UTF-8 encoding of the "a
umlaut").
Can I / should I do something like
binmode($r,":$charset"); # ??
TIA
Addendum : I added some logging to the ResponseHandler as follows :
PARAM: while (defined($line = <$form_fh>)) {
if ($Debug > 1) {
$r->log->warn(" input line is [$line], utf8 flag : " . (Encode::is_utf8($line) ? "y" :
"n"));
}
The corresponding line in the log, for a line containing the word "männlich",
is :
[Thu Nov 29 10:34:37 2012] [warn] [client 192.168.245.129] input line is [\t\t\t\tname="ANSPR" type="radio" value="m" id="ANSPR"> m\xc3\xa4nnlich\n], utf8 flag : y
Of course, as is usual in the type of case, one never knows how the logfile itself is
written..
But it does confirm that, as read in the Handler, the string is properly encoded
internally in perl, with the utf8 flag set.
However, when I look in the result as received by the browser,
- the browser says that the page received is encoded as iso-8859-1
- the browser's "view page source" confirms that this character is (incorrectly)
represented by 2 bytes :
männlich
Charset in response
Hi.
I have a problem with a PerlResponseHandler, regarding the character set used in the
response to a request.
Basically, the question is : how to I set the character set properly for the
"handle" used in
$r->print("string") ?
(where string can be "äéèöü" for example)
Neither of the following (which I do before starting to print output) seems to
work :
$r->headers_out->unset('content-type');
$r->headers_out->set('content-type','text/html;charset=');
or
$r->content_type('text/html;charset=');
When I say that it doesn't work, I mean in fact :
- the "Content-Type" response header sent by the server is properly set according to what
I do above (as verified in a browser plugin)
- but if what I print contains "accented" characters, they are not being
encoded properly
So, do I need to set something else so that the $r->print(string) will output "string"
properly ?
Background :
My PerlResponseHandler reads a html file from disk, replaces some strings into it, and
sends the result out via $r->print.
The source html file can be encoded in iso-8859-1 or UTF-8, and it contains a proper
declaration of the charset under which it is really encoded :
or
To read the file, I first open it "raw", read a few lines, checking for the above
tag. If found, I note the charset (say in $charset), close the file, and re-open it as
open(my $fh,"<:encoding($charset)", $file);
(note : if $charset is "UTF-8", then the open becomes
open(my $fh,'<:utf8', $file);)
I also at that point set the response charset by one of the means above.
Then I read the file line by line, substituting some strings in the line, and print out
the line via
$r->print($line);
etc..
My problem is that, if the input file is for example iso-8859-1 and contains the word
"Männer", the output comes out as "M(A tilde)(some byte)nner" (the bytes corresponding to
the UTF-8 encoding of the "a umlaut").
Can I / should I do something like
binmode($r,":$charset"); # ??
TIA
Re: get the incoming TCP protocol type
Torsten Förtsch wrote:
On 11/26/2012 09:05 AM, André Warnier wrote:
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritecond
there is apparently a "server variable" HTTPS which can be tested in a
RewriteCond, and which looks just like what I need :
HTTPS
Will contain the text "on" if the connection is using SSL/TLS, or
"off" otherwise. (This variable can be safely used regardless of whether
or not mod_ssl is loaded).
Now I just have to find out how I can actually access such a "server
variable" inside a mod_perl handler. But that should be a breeze,
considering the nice online mod_perl documentation, right ?
Let's see if I can beat Torsten to it..
The problem is this "variable" is not something that is stored along
with the other request data. It is just the temporary result of a
function call.
What mod_rewrite does here to provide the "variable" is 2 things:
1) it looks for an optional function (this is a thing APR has invented)
named "ssl_is_https". In C it looks something like this:
APR_OPTIONAL_FN_TYPE(ssl_is_https) *is_https;
is_https=APR_RETRIEVE_OPTIONAL_FN(ssl_is_https);
If the function cannot be found HTTPS will be off because mod_ssl is not
loaded.
2) then it calls the function, which returns a boolean value.
Apache2::ModSSL does exactly the same.
To make this variable accessible by means of mod_rewrite to mod_perl you
can:
RewriteCond %{HTTPS} =on
RewriteRule .? - E=HTTPS:42
Later on in Perl you can ask
if ($r->subprocess_env->{HTTPS} eq "42") ...
Mod_rewrite normally works in the uri translation phase, except when it
is called in a , or block or a .htaccess
file. In this case it works in the fixup phase. Unfortunately,
mod_rewrite installs its handler with APR_HOOK_FIRST priority while
mod_perl uses APR_HOOK_REALLY_FIRST. That means a PerlFixupHandler is
called *before* mod_rewrite in directory context.
Between the two of you, we're seeing the light at the end of the tunnel..
Many thanks. I don't think that this is really documented anywhere, so my chances of
finding this by myself were rather low to begin with.
I must say that I slightly prefer Torsten's solution, which looks easier (some of the URLs
to proxy already have a query string, for instance).
But I can see also that I'll have to seriously document this in the code, otherwise some
poor maintainer is going to have a hard time in a couple of years from now, trying to
figure out what is going on here. Specially if he has never heard of Deep Thought.
Re: get the incoming TCP protocol type
Vincent Veyron wrote:
Le samedi 24 novembre 2012 à 16:58 +0100, André Warnier a écrit :
Is there somewhere a "is_secure()" or something which provides that ?
Or can I rely on the presence/absence of some request header ?
Apache's mod_rewrite has the HTTPS RewriteCond directive, which I use to
enforce https access on a site like so:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
May be you can use this to mark the request somehow?
My problem is slightly different : I don't need to "enforce" HTTPS on the requests which I
proxy; I need to determine if the incoming request was made via HTTPS.
But your tip above actually pointed to something which may be of use to me : in
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritecond
there is apparently a "server variable" HTTPS which can be tested in a RewriteCond, and
which looks just like what I need :
HTTPS
Will contain the text "on" if the connection is using SSL/TLS, or "off" otherwise.
(This variable can be safely used regardless of whether or not mod_ssl is loaded).
Now I just have to find out how I can actually access such a "server variable" inside a
mod_perl handler. But that should be a breeze, considering the nice online mod_perl
documentation, right ?
Let's see if I can beat Torsten to it..
Re: get the incoming TCP protocol type
Torsten Förtsch wrote: On 11/24/2012 08:11 PM, Fred Moyer wrote: On Sat, Nov 24, 2012 at 7:58 AM, André Warnier wrote: Inside a mod_perl2 request handler, how can I find out if the current request was received via HTTP or HTTPS ? Torsten is the author of this module, so he can explain it in more detail, but it looks like it can do part of what you need: https://metacpan.org/module/Apache2::ModSSL That is, of course, what I would use. If I recall correctly, the module was written to have access to the SSL related information *prior to* the response phase. If you need it only in the response phase you can have mod_ssl export almost all of the stuff accessible via Apache2::ModSSL as environment variables accessible via $r->subprocess_env. I'm in the Fixup phase. Hmm. C:\develop\06_SVN\AP2lib\trunk\modlib\PROXY>ppm search Apache2::ModSSL Downloading ActiveState Package Repository packlist...done Updating ActiveState Package Repository database...done Downloading bribes-5.12 packlist...not modified Downloading trouchelle-5.12 packlist...not modified Downloading winnipeg-5.12 packlist...not modified Downloading wxperl packlist...not modified *** no packages matching 'Apache2::ModSSL' found *** No Win32 port available for that, I guess. (We work mostly (whenever we can get away with it, essentially) on Linux servers, but try to keep our solutions portable to Windows too, since we occasionally have clients that insist on it.) Building it on Windows from the tar.gz doesn't seem to work either, as it appears to require gcc (and probably a lot of other things not available on my XP laptop). However, the real target system this time is Linux, and it's kind of one-of-a-kind for now, so let's try : root@arthur:~# apt-cache search apache2 | grep SSL libapache2-mod-log-sql-ssl - Use SQL to store/write your apache queries logs - SSL extension libapache2-mod-gnutls - Apache module for SSL and TLS encryption with GnuTLS Hmm, no handy Debian package. So, the hard way : GOT /root/.cpan/sources/authors/id/O/OP/OPI/CHECKSUMS.tmp8430 Checksum for /root/.cpan/sources/authors/id/O/OP/OPI/Apache2-ModSSL-0.08.tar.gz ok CPAN: Archive::Tar loaded ok (v1.88) Apache2-ModSSL-0.08/ Apache2-ModSSL-0.08/t/ Apache2-ModSSL-0.08/t/conf/ Apache2-ModSSL-0.08/t/conf/localhost.cert Apache2-ModSSL-0.08/t/conf/extra.conf.in Apache2-ModSSL-0.08/t/TestSSL/ Apache2-ModSSL-0.08/t/TestSSL/is_https.pm Apache2-ModSSL-0.08/t/TestSSL/lookup.pm Apache2-ModSSL-0.08/t/2lookup.t Apache2-ModSSL-0.08/t/1is_https.t Apache2-ModSSL-0.08/t/TEST.PL Apache2-ModSSL-0.08/META.yml Apache2-ModSSL-0.08/Changes Apache2-ModSSL-0.08/perl-Apache2-ModSSL.spec Apache2-ModSSL-0.08/MANIFEST Apache2-ModSSL-0.08/Makefile.PL Apache2-ModSSL-0.08/lib/ Apache2-ModSSL-0.08/lib/Apache2/ Apache2-ModSSL-0.08/lib/Apache2/ModSSL.pm Apache2-ModSSL-0.08/README Apache2-ModSSL-0.08/mk_README.sh Apache2-ModSSL-0.08/ModSSL.xs CPAN: File::Temp loaded ok (v0.22) CPAN.pm: Going to build O/OP/OPI/Apache2-ModSSL-0.08.tar.gz Could not figure out which apxs to use. Try the -apxs option. Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site] OPI/Apache2-ModSSL-0.08.tar.gz /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK Running make test Make had some problems, won't test Running make install Make had some problems, won't install root@arthur:~# Ok, I'm a bit rusty about building from CPAN. This is Linux Debian : root@arthur:~# uname -a Linux arthur 2.6.32-5-686 #1 SMP Mon Mar 26 05:20:33 UTC 2012 i686 GNU/Linux Perl is : root@arthur:~# perl -vv This is perl, v5.10.1 (*) built for i486-linux-gnu-thread-multi (with 56 registered patches, see perl -V for more detail) Apache httpd is : [Mon Nov 12 15:01:23 2012] [notice] Apache/2.2.16 (Debian) DAV/2 SVN/1.6.12 mod_jk/1.2.30 PHP/5.3.3-7+squeeze8 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations But I do not find an "apxs" anywhere. Do I need to install some "dev" package to get it ? root@arthur:~# apt-cache search apache2 | grep dev apache2-prefork-dev - Apache development headers - non-threaded MPM apache2-threaded-dev - Apache development headers - threaded MPM libapache2-mod-perl2-dev - Integration of perl with the Apache2 web server - development files ?
get the incoming TCP protocol type
Hi. Inside a mod_perl2 request handler, how can I find out if the current request was received via HTTP or HTTPS ? I mean : The client (browser e.g.) gets a URL "http://host.x.y/path1/path2..";, and - translates host.x.y to an IP - makes a connection to that IP (and port) - sends a request like : GET /path1/path2.. HTTP/1.1 Host: host.x.y ... OR The client (browser e.g.) gets a URL "https://host.x.y/path1/path2..";, and - translates host.x.y to an IP - makes an *SSL* connection to that IP (and port) - sends a request like : GET /path1/path2.. HTTP/1.1 Host: host.x.y ... and Inside a handler, I can get $r->hostname ==> host.x.y $r->uri and $r->unparsed_uri ==> /path1/path2.. and I can also get the port on which the request was received (presumably), via $r->get_server_port but that is not really a guarantee, any port could be set for either HTTP or HTTPS. and then I see $r->proto and $r->proto_num but these are relative to the protocol string as it appears in the first request line, not to the type of connection that was used for the request. And in the request, I guess it would always be HTTP/1.1, or ? (I don't have a HTTPS host right now to check this) And I haven't really found anything yet in Apache2:RequestRec, Apache2::Connection or Apache2::ServerRec which would provide that information. Is there somewhere a "is_secure()" or something which provides that ? Or can I rely on the presence/absence of some request header ? Help.. The point is, I'd like to write the handler once, and use it inside a HTTP or a HTTPS host indifferently. And if possible, I'd also like to avoid having to tell the handler where he lives via some PerlSetVar just for that. But maybe that's the easiest solution ?
use "global" data in handler (was : custom proxy setup with mod_perl)
Hi.
This refers indirectly to the thread "custom proxy setup with mod_perl", but is more
general, I believe.
For the PerlFixupHandler which was discussed before, I need to compare the current request
URL to a predefined static list of URLs, to decide how exactly to proxy this call.
At the moment, there are about 15 URLs in that list; and I believe that there might, maybe
in some cases, be up to 100.
I suppose that I could make this list of URLs available to the handler by doing something
like this :
...
PerlFixupHandler My::Proxy->handler
PerlAddVar CHKU "http://www.site-1.com/";
PerlAddVar CHKU "http://www.site-2.org/path?query";
PerlAddVar CHKU "http://www.site-3.biz/";
PerlAddVar CHKU "http://www.site-4.edu/";
etc.. 50 times
and then do
my @list = $r->dir_config('CHKU');
in the handler.
On the other hand, I could also put these URLs in a separate configuration text file, and
have the handler read it at each invocation :
...
PerlFixupHandler My::Proxy->handler
PerlSetVar URL_LIST "/etc/apache2/conf/urllist.txt"
and in the handler :
my $urllist = $r->dir_config('URL_LIST') || "default.list";
my @list = ();
my $fh;
open($fh,'<',$urllist) or safe_die;
@list = <$fh>;
close $fh;
But neither of these is very satisfying.
The first one above is OK up to 10-20 URLs, but becomes a bit unsightly and
clumsy for more.
The second one has the handler read and parse a file at each invocation (even if the
request URL turns out not to be in the list, and the call should just be proxy-ed as is).
Sounds inefficient.
So, I would like to do this :
Package My::Proxy;
our $URLS;
sub handler {
my $r = shift;
unless (defined($URLS)) {
my $urllist = $r->dir_config('URL_LIST') ||
"/etc/apache2/default_urls.list";
my $fh;
my @list;
open($fh,'<',$urllist) or safe_die;
@list = <$fh>;
close $fh;
$URLS = \@list; # or = [ @list ] ??
}
.. use @$URLS, read-only ..
}
As I understand the above, in a pre-fork MPM, each time Apache forks a new child, at the
first handler invocation $URLS will be undef, and thus the code in the handler will define
it, as a reference to an array of URLs read from the file.
And from then on, the list accessible through $URLS should remain available and unvariable
at each subsequent invocation of this handler (in this child), as long as this Apache
child process lives.
First, I may be wrong in my understanding. (that's a question).
Second, if I am right in the above, then does this same understanding extend to all
possible Apache MPMs ? Or am I creating a horrible risk of some race condition, or memory
leak here ?
Re: custom proxy setup with mod_perl
Fred Moyer wrote:
On Fri, Nov 23, 2012 at 2:18 PM, André Warnier wrote:
Fred Moyer wrote:
You might want to take a look at a mod_perl based proxy module I wrote
- https://metacpan.org/module/Apache2::Proxy
It was used in conjunction with Perlbal and a couple other tricks, but
was pretty speedy given the crude nature of how I implemented it.
No offense intended, Fred, but without much of a documentation, this is bit
above my level. I have trouble even understanding where it fits in.
None taken, you're quite right, this needs (more) documentation. It
was open sourced when still in rough form. I'll send a ping when I get
it cleaned up and 0.05 released. Anyway, here's the basic way I used
it. Torsten's solution is probably technically more adept, but I
couldn't do what I needed to using filtering, so I had to write this.
SetHandler modperl
PerlHeaderParserHandler Apache2::Const::OK
PerlAccessHandler Apache2::Const::OK
PerlAuthenHandler Apache2::Const::OK
PerlAuthzHandlerApache2::Const::OK
PerlTypeHandler Apache2::Const::OK
PerlFixupHandlerApache2::Const::OK
PerlResponseHandler My::Proxy->handler
package My::Proxy;
use base 'Apache2::Proxy';
sub handler {
my ($r, $class) = @_;
# examine request to see if it needs to be modified
# if not, pass to Apache2::Proxy
return $class->SUPER::handler($r);
# else fixup the request as needed.
}
Ok, get it, thanks.
All-in-one, as a substitute for mod_proxy.
I will have a second look now.
