UTF-8 in mod_perl
Hi. I was wondering how I could set the mod_perl (1.x) STDOUT (and STDERR) to expect utf8 char encoding? In perlrun, you can just set it by using -CS parameter, ie, `perl -CS -le 'print olé'`, or at runtime binmode(STDOUT, :utf8); Thanks, Cristina -- Alanna Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders
Re: DBI and threaded MPM
Anthony Gardner wrote: Perrin, I never received your mail (actually, I hardly receive any mails form this list) I have to go to the archives to see if I've received any replies or to see what's been posted in general!! You may want to check with your email admin on this. There's posting on this list almost daily!
Re: UTF-8 in mod_perl
You will want to do 2 things: 1. Set the content type to utf8 ($r-content_type) 2. Encode your output to utf8 (if it's not done already. Sometimes it's just latin1) Cristina Nunes wrote: Hi. I was wondering how I could set the mod_perl (1.x) STDOUT (and STDERR) to expect utf8 char encoding? In perlrun, you can just set it by using -CS parameter, ie, `perl -CS -le 'print olé'`, or at runtime binmode(STDOUT, :utf8); Thanks, Cristina
how do I clear stale POST data?
Situation: = User puts in username password into a form (uses POST to send data) to log in. = When the user is done, he/she logs out. = When clicking back (a couple of time) the user eventually reaches the page prompting for username password Problem: When the user hits refresh or forward, their magically logged in again. Thanks, Scott
Re: how do I clear stale POST data?
On Wed, 2007-07-11 at 08:43 -0400, Scott Kaplan wrote: Situation: = User puts in username password into a form (uses POST to send data) to log in. = When the user is done, he/she logs out. = When clicking back (a couple of time) the user eventually reaches the page prompting for username password Problem: When the user hits refresh or forward, their magically logged in again. the data is kept client side, so you can't clear that. but you can: 1) set an immediate expiry time on the login page (which may or may not work) 2) add a token to the login form, so that the old form would no longer be valid Clint
Re: how do I clear stale POST data?
On 11 Jul at 13:50 Clinton Gormley [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED] On Wed, 2007-07-11 at 08:43 -0400, Scott Kaplan wrote: Situation: = User puts in username password into a form (uses POST to send data) to log in. = When the user is done, he/she logs out. = When clicking back (a couple of time) the user eventually reaches the page prompting for username password Problem: When the user hits refresh or forward, their magically logged in again. the data is kept client side, so you can't clear that. but you can: 1) set an immediate expiry time on the login page (which may or may not work) 2) add a token to the login form, so that the old form would no longer be valid Try setting autocomplete=off either in the form definition, or in the text input for the username/password. input name=pass type=password value= class=textbox size=15 autocomplete=off -- Tony van der Hoff| mailto:[EMAIL PROTECTED] Buckinghamshire, England
Re: how do I clear stale POST data?
On 7/11/07, Scott Kaplan [EMAIL PROTECTED] wrote: Problem: When the user hits refresh or forward, their magically logged in again. Solution: http://en.wikipedia.org/wiki/Post/Redirect/Get - Perrin
Re: mod_perl lazy loading modules with eval in custom lib
Perrin Harkins schreef: On 7/7/07, Christiaan Kras [EMAIL PROTECTED] wrote: Because in my error messages it clearly says it can't find the modules in @INC. Then it shows all the paths in @INC and my custom lib isn't set there, instead, @INC is at it's original state. Okay, you said you don't add to @INC at startup. How do you adjust @INC? Is it possible you have a code path that doesn't set @INC? Is it possible that some of your code is still running under CGI? - Perrin I add to @INC with use lib qw(/my/path) . All the other modules I load continue to work fine. Just those that use lazy loading fail infrequently. I've build it in a way that it will run under CGI as well as mod-perl (using perl-script handler). For a temporary solution I've added a CGI script that's exactly the same as the perl script, but run under CGI, to generate my Excel files without error. Not a very comforting solution, but for now it works. Although I would love to know the real solution. Thanks. -- Christiaan Kras
Re: DBI and threaded MPM
On 7/11/07, Anthony Gardner [EMAIL PROTECTED] wrote: A. We recently went live with a DB application and the system ground to a halt. It could be due to many things, but the thing I'm looking at is the fact that we had many network connections. I then found the info about Databases and threaded MPM. From what I understand, DB connections created at server startup are not shared amongst threads. That's correct. Each process or thread must have a separate connection. Before you can fix your problem, you need to find out what the problem is. It sounds like you haven't done much configuration, so the most likely problem is that you have MaxClients set really high and you are using up all the memory on the machine and going into swap. There's lots of advice on the mod_perl site about how to correctly tune MaxClients and related settings. - Perrin
Re: how do I clear stale POST data?
On Jul 11, 2007, at 8:43 AM, Scott Kaplan wrote: Situation: = User puts in username password into a form (uses POST to send data) to log in. = When the user is done, he/she logs out. = When clicking back (a couple of time) the user eventually reaches the page prompting for username password Problem: When the user hits refresh or forward, their magically logged in again. What everyone else brought up is correct... I just wanted to add -- are you sure that you're not running into a scoping issue, and reusing a login variable on the server side ? a little mistake like that can be fixed by moving a 'my' from a package into a sub. thats a common mistake that could result in that effect. the other answers are much more specific to your problem. // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | CEO/Founder SyndiClick Networks | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Founder/CTO/CVO | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: mod_perl lazy loading modules with eval in custom lib
On 7/11/07, Christiaan Kras [EMAIL PROTECTED] wrote: I add to @INC with use lib qw(/my/path) . All the other modules I load continue to work fine. Just those that use lazy loading fail infrequently. Okay, I think I see the problem. When you change @INC during a request, the change only lasts for the length of that one request: http://perl.apache.org/docs/2.0/user/coding/coding.html#Request_localized_Globals Because you do a use lib, @INC is only set the first time you run this script. Change it to this: unshift @INC, qw(/my/path/); - Perrin
Re: mod_perl lazy loading modules with eval in custom lib
Perrin Harkins schreef: On 7/11/07, Christiaan Kras [EMAIL PROTECTED] wrote: I add to @INC with use lib qw(/my/path) . All the other modules I load continue to work fine. Just those that use lazy loading fail infrequently. Okay, I think I see the problem. When you change @INC during a request, the change only lasts for the length of that one request: http://perl.apache.org/docs/2.0/user/coding/coding.html#Request_localized_Globals Because you do a use lib, @INC is only set the first time you run this script. Change it to this: unshift @INC, qw(/my/path/); - Perrin Thanks. I will try that. So basicly, the modules that are loaded at the first request will stay in memory, but @INC will get reset? ...testing... Wow. I never noticed it. In my app I have runmode that shows me %ENV and @INC. At the first request my custom path was in there. And at the second request it wasn't. But after a few more requests it's still there. Weird behaviour? Anyway, thanks. I'll try it later on. I'll post again if it doesn't help. Just a quick note: unshift removes the first record from the array. But what if my path isn't in @INC at a second request. That would remove a normal path that's always around wouldn't it? Guess I'll just have to try and see :-). Thanks. -- Christiaan Kras
Re: mod_perl lazy loading modules with eval in custom lib
Wow. I never noticed it. In my app I have runmode that shows me %ENV and @INC. At the first request my custom path was in there. And at the second request it wasn't. But after a few more requests it's still there. Weird behaviour? All that means is that you're hitting a new child for the first time. Anyway, thanks. I'll try it later on. I'll post again if it doesn't help. Just a quick note: unshift removes the first record from the array. But what if my path isn't in @INC at a second request. That would remove a normal path that's always around wouldn't it? Guess I'll just have to try and see :-). Thanks. You're thinking of shift :) unshift is the opposite - it adds the new path onto the front of @INC. Clint
Re: mod_perl lazy loading modules with eval in custom lib
On 7/11/07, Christiaan Kras [EMAIL PROTECTED] wrote: Thanks. I will try that. So basicly, the modules that are loaded at the first request will stay in memory, but @INC will get reset? Yes. It's a simulation of CGI behavior. The only reason your CGI scripts don't have this problem is that they execute the use lib on every request, since they are compiling from scratch every time. Wow. I never noticed it. In my app I have runmode that shows me %ENV and @INC. At the first request my custom path was in there. And at the second request it wasn't. But after a few more requests it's still there. Weird behaviour? You're probably just seeing a new child process compile the script for the first time. Just a quick note: unshift removes the first record from the array. No, it adds to the beginning of the array. - Perrin
Re: mod_perl lazy loading modules with eval in custom lib
Perrin Harkins schreef: On 7/11/07, Christiaan Kras [EMAIL PROTECTED] wrote: Thanks. I will try that. So basicly, the modules that are loaded at the first request will stay in memory, but @INC will get reset? Yes. It's a simulation of CGI behavior. The only reason your CGI scripts don't have this problem is that they execute the use lib on every request, since they are compiling from scratch every time. I've read about it. I was sure I checked it. Wow. I never noticed it. In my app I have runmode that shows me %ENV and @INC. At the first request my custom path was in there. And at the second request it wasn't. But after a few more requests it's still there. Weird behaviour? You're probably just seeing a new child process compile the script for the first time. Just a quick note: unshift removes the first record from the array. No, it adds to the beginning of the array. - Perrin Oops, my bad. *ashamed* Anyway. I've tested it, and now in the runmode that show's me @INC it keeps the path I've set. I've tried a number of Excel exports as well and none of them were faulty. However, I will keep a look at my logfile. But I hope this solves the problem. By the way, I've used push() to add my path to @INC before. But that didn't work out. Was that because push() puts the path at the end of @INC? Shouldn't really matter should it? Although it's possible I used it after loading my modules (not in the startup sub). For now I seem to be helped. Thanks again :-). -- Christiaan Kras
Re: mod_perl lazy loading modules with eval in custom lib
On 7/11/07, Christiaan Kras [EMAIL PROTECTED] wrote: By the way, I've used push() to add my path to @INC before. But that didn't work out. It should work fine. The reason people typically use unshift for this is that it lets modules in your local path override ones in the system path. - Perrin
Re: mod_perl lazy loading modules with eval in custom lib
Perrin Harkins schreef: On 7/11/07, Christiaan Kras [EMAIL PROTECTED] wrote: By the way, I've used push() to add my path to @INC before. But that didn't work out. It should work fine. The reason people typically use unshift for this is that it lets modules in your local path override ones in the system path. - Perrin I see. Well, it still seems to work but I'll get back to the list if it isn't. Although I'm sure now all is well. -- Christiaan Kras
Re: First time being here, Need Big help here!
Hi all, Finally I get this working, get Apache::AuthDigest installed. I was idiot that I didn't have Apache src directory when I install the AuthDigest. AuthDigest needs Apache src files. Thanks, everyone! Have a nice day:) xin [EMAIL PROTECTED] wrote: Yes - thanks. On Mon, 09 Jul 2007 17:26:15 +0800 [EMAIL PROTECTED] wrote: Don't understand what you mean. To rephrase myself: Apache 1.3 uses modperl 1 Apache 2.0 and 2.2 uses modperl 2 Does this help? [EMAIL PROTECTED] wrote: In the sentence Do note that modperl1 is that mod_perl 1.x or is that an extra 'el'? i assume mod_perl 2 works with apache 2.x On Mon, 09 Jul 2007 11:11:13 +0800 [EMAIL PROTECTED] wrote: I doubt. Apache2 is a major overhaul. You're better off installing apache2 or 2.2 from scratch. Do note that modperl1 is not compatible with apache 2
svn commit: r555364 - /perl/modperl/branches/1.x/Makefile.PL
Author: gozer
Date: Wed Jul 11 11:42:38 2007
New Revision: 555364
URL: http://svn.apache.org/viewvc?view=revrev=555364
Log:
Get rid of a very old broken piece of Makefile.PL code
that post processes PERL_EXTRA_CLFAGS, effectively doing
s/,/ /g.
That's breaking CFLAGS with valid ',' in their values, like
-Wl,foo.
Modified:
perl/modperl/branches/1.x/Makefile.PL
Modified: perl/modperl/branches/1.x/Makefile.PL
URL:
http://svn.apache.org/viewvc/perl/modperl/branches/1.x/Makefile.PL?view=diffrev=555364r1=555363r2=555364
==
--- perl/modperl/branches/1.x/Makefile.PL (original)
+++ perl/modperl/branches/1.x/Makefile.PL Wed Jul 11 11:42:38 2007
@@ -543,11 +543,6 @@
}
}
-if ($PERL_EXTRA_CFLAGS) {
-$PERL_EXTRA_CFLAGS = join( , split(,, $PERL_EXTRA_CFLAGS));
-$PERL_EXTRA_CFLAGS =~ s/\s+/ /g;
-}
-
if ($PERL_DEBUG) {
my $lib = $Config{archlibexp}/CORE/libperld$Config{lib_ext};
if (-e $lib) {
