Re: Javascript - just say no(t required)
> "Les" == Les Mikesell <[EMAIL PROTECTED]> writes: Les> I think it is also very reasonable to store user-selected preferences Les> in cookies, especially for things likes sizes, colors, fonts for Les> certain pages. Why should the server side have to store millions Les> of things like that? Even if it does, the choices may be different Les> for the same user running a different browser. Normally you Les> would have some default that would work for the cookie-challenged Les> folks anyway. Please remember that the cookie space is spec'ed to be limited. So your cookie may get pushed out for others. So there'd better be a way to trivially reload all that stuff, or your customers will be angry. Might as well be nice, store the info server side, and treat it like a login. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [OT] Rewrite arguments?
- Original Message -
From: "Dave Kaufman" <[EMAIL PROTECTED]>
To: "Les Mikesell" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, January 05, 2001 11:09 PM
Subject: Re: [OT] Rewrite arguments?
> > One of us is missing something. I hope it is me, but when I turn on
> > rewrite logging, the input side contains only the location portion. The
> > argument string has already been stripped.
>
> the query string is stripped from what the rewrite rule is matching, yes.
but
> you can use a RewriteCond above the rule to test %{QUERY_STRING} against a
> regexp pattern, and store backreferences from it as %1, %2...etc.
That's it - thank you very much. I had seen how to match and reuse chunks
in the RewriteCond, but somehow missed the ability to substitute them
in the RewriteRule. I should have known it was too useful to have
been left out.
> # match and store the interesting arg values as backrefs
> RewriteCond %{QUERY_STRING} arg1=([0-9]+)&arg2=([0-9]+)
> # build a new QS for the proxy url
> RewriteRule ^/cgi-bin/prog
> http://otherhost/prog?newarg1=%1&arg2=%2&uname=me&pwd=password [R,L]
Since I only want to substitute one argument name without knowing much
else I think this will work:
RewriteCond %{QUERY_STRING} (.*)(arg1=)(.*)
RewriteRule ^/cgi-bin/prog
http://otherhost/prog?%1newarg1=%2&uname=me&pwd=password [P,L]
(I want a proxy request to hide the password usage, not a client redirect
but either could work)
Les Mikesell
[EMAIL PROTECTED]
Re: [OT] Rewrite arguments?
Would something like RewriteMap work? http://httpd.apache.org/docs/mod/mod_rewrite.html#RewriteMap At 09:43 PM 1/5/01 -0600, Les Mikesell wrote: >- Original Message - >From: "G.W. Haywood" <[EMAIL PROTECTED]> >To: "Les Mikesell" <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Friday, January 05, 2001 1:44 PM >Subject: Re: [OT] Rewrite arguments? > > > > On Thu, 4 Jan 2001, Les Mikesell wrote: > > > > > This may or may not be a mod_perl question: > > > > Probably not :) > >I have a feeling it is going to end up being possible only >with LWP... > > > > I want to change the way an existing request is handled and it can be > done > > > by making a proxy request to a different host but the argument list must > > > be slightly different.It is something that a regexp substitution can > > > handle and I'd prefer for the front-end server to do it via mod_rewrite > > > but I can't see any way to change the existing arguments via > RewriteRules. > > > > I don't exactly understand your problem, but from what I can see you > > should be able to do what you want with mod_rewrite if you just use a > > regexp which contains a question mark. Have I missed something? > >One of us is missing something. I hope it is me, but when I turn on >rewrite logging, the input side contains only the location portion. The >argument string has already been stripped. Apparently it is put back >in place after the substition, since ^(.*)$ http://otherserver$1 [P] will >send the same arguments on to the downstream host. > > > Does this extract from the docs help? > > -- > > One more note: You can even create URLs in the substitution string > containing > > a query string part. Just use a question mark inside the substitution > string > > to indicate that the following stuff should be re-injected into the > > QUERY_STRING. When you want to erase an existing query string, end the > > substitution string with just the question mark. > >This allows adding additional arguments, or deleting them all. I want to >change an existing one and add some more. Something like: >/cgi-bin/prog?arg1=22&arg2=24 should become: >http://otherhost.domain/prog?newarg1=22&arg2=24&uname=me&pwd=password > > > > Note: There is a special feature: When you prefix a substitution field > > with http://thishost[:thisport] then mod_rewrite automatically strips > > it out. This auto-reduction on implicit external redirect URLs is a > > useful and important feature when used in combination with a > > mapping-function which generates the hostname part. Have a look at > > the first example in the example section below to understand this. > >That won't affect this case. The hostname will be fixed and always >require the proxy mode. > >Les Mikesell > [EMAIL PROTECTED]
Re: [OT] Rewrite arguments?
"Les Mikesell" <[EMAIL PROTECTED]> wrote:
>
> I have a feeling it is going to end up being possible only
> with LWP...
>
> > I don't exactly understand your problem, but from what I can see you
> > should be able to do what you want with mod_rewrite if you just use a
> > regexp which contains a question mark. Have I missed something?
>
> One of us is missing something. I hope it is me, but when I turn on
> rewrite logging, the input side contains only the location portion. The
> argument string has already been stripped.
the query string is stripped from what the rewrite rule is matching, yes. but
you can use a RewriteCond above the rule to test %{QUERY_STRING} against a
regexp pattern, and store backreferences from it as %1, %2...etc.
> > Does this extract from the docs help?
> > --
> > One more note: You can even create URLs in the substitution string
containing
> > a query string part. Just use a question mark inside the substitution
string
> > to indicate that the following stuff should be re-injected into the
> > QUERY_STRING. When you want to erase an existing query string, end the
> > substitution string with just the question mark.
> This allows adding additional arguments, or deleting them all. I want to
> change an existing one and add some more. Something like:
> /cgi-bin/prog?arg1=22&arg2=24 should become:
>http://otherhost.domain/prog?newarg1=22&arg2=24&uname=me&pwd=password
Also from the RTFM dept:
'qsappend|QSA' (query string append)
This flag forces the rewriting engine to append a query string part in the
substitution string to the existing one instead of replacing it. Use this when
you want to add more data to the query string via a rewrite rule.
a possibly relevant example would be:
# match and store the interesting arg values as backrefs
RewriteCond %{QUERY_STRING} arg1=([0-9]+)&arg2=([0-9]+)
# build a new QS for the proxy url
RewriteRule ^/cgi-bin/prog
http://otherhost/prog?newarg1=%1&arg2=%2&uname=me&pwd=password [R,L]
(but without the linewrap, of course)
in this example you dont need the qsappend flag because we reconstructed the
entire query string. if you werent renaming agr1 to newarg1 (or if ther may
have been other args you want to pass on) you could have just done:
# just test for the presence of our args in the QS
# and make the whole thing conditional on that
RewriteCond %{QUERY_STRING} arg1=[0-9]+&arg2=[0-9]+
#and rewite, injecting just the new args
RewriteRule ^/cgi-bin/prog
http://otherhost/prog?uname=me&pwd=password [QSA,R,L]
and the rw engine will add uname & pwd to any existing querystring that was
present
hope this helps,
-dave
Re: [OT] Rewrite arguments?
- Original Message - From: "G.W. Haywood" <[EMAIL PROTECTED]> To: "Les Mikesell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 05, 2001 1:44 PM Subject: Re: [OT] Rewrite arguments? > On Thu, 4 Jan 2001, Les Mikesell wrote: > > > This may or may not be a mod_perl question: > > Probably not :) I have a feeling it is going to end up being possible only with LWP... > > I want to change the way an existing request is handled and it can be done > > by making a proxy request to a different host but the argument list must > > be slightly different.It is something that a regexp substitution can > > handle and I'd prefer for the front-end server to do it via mod_rewrite > > but I can't see any way to change the existing arguments via RewriteRules. > > I don't exactly understand your problem, but from what I can see you > should be able to do what you want with mod_rewrite if you just use a > regexp which contains a question mark. Have I missed something? One of us is missing something. I hope it is me, but when I turn on rewrite logging, the input side contains only the location portion. The argument string has already been stripped. Apparently it is put back in place after the substition, since ^(.*)$ http://otherserver$1 [P] will send the same arguments on to the downstream host. > Does this extract from the docs help? > -- > One more note: You can even create URLs in the substitution string containing > a query string part. Just use a question mark inside the substitution string > to indicate that the following stuff should be re-injected into the > QUERY_STRING. When you want to erase an existing query string, end the > substitution string with just the question mark. This allows adding additional arguments, or deleting them all. I want to change an existing one and add some more. Something like: /cgi-bin/prog?arg1=22&arg2=24 should become: http://otherhost.domain/prog?newarg1=22&arg2=24&uname=me&pwd=password > Note: There is a special feature: When you prefix a substitution field > with http://thishost[:thisport] then mod_rewrite automatically strips > it out. This auto-reduction on implicit external redirect URLs is a > useful and important feature when used in combination with a > mapping-function which generates the hostname part. Have a look at > the first example in the example section below to understand this. That won't affect this case. The hostname will be fixed and always require the proxy mode. Les Mikesell [EMAIL PROTECTED]
Re: Javascript - just say no(t required)
- Original Message - From: "dreamwvr" <[EMAIL PROTECTED]> To: "Randal L. Schwartz" <[EMAIL PROTECTED]> Cc: "Gunther Birznieks" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 05, 2001 12:00 PM Subject: Re: Javascript - just say no(t required) > hi, >Seems to me the only reasonable usage for cookies that does not > seem to be abuse.org is as a temporary ticket granting system.. so > the next time you want to get a byte you need a ticket to goto the > smorg.. I think it is also very reasonable to store user-selected preferences in cookies, especially for things likes sizes, colors, fonts for certain pages. Why should the server side have to store millions of things like that? Even if it does, the choices may be different for the same user running a different browser. Normally you would have some default that would work for the cookie-challenged folks anyway. Les Mikesell [EMAIL PROTECTED]
ANNOUCE: HTML::Mason 0.896
The URL http://www.masonhq.com/download/HTML-Mason-0.896.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JS/JSWARTZ/HTML-Mason-0.896.tar.gz size: 258678 bytes md5: 5b9d0f654066137ec0d05862c06ccbcc This release fixes a few minor bugs and documentation glitches, and is our latest 1.0 release candidate. I encourage everyone currently using 0.8x to upgrade to this release and report any bugs to the user's list. I'd especially like to confirm that the PerlFreshRestart bug has been fixed. Thanks Jon Changes in 0.896: - Fixed bug preventing Mason from working with PerlFreshRestart. - Fixed use_reload_file to work as documented and not stat() source files. (submitted by Benjamin John Turner) - Fixed display in Apache::Status. - Documented the significance of ordering in <%args> sections. - Fixed documentation of %ARGS with regards to hashes passed in query string. (suggested by Adam Stubbs) - Added version # to 'use Apache::Session::File' in session_handler.pl. - Fixed preloads documentation to match reality.
Strange log entry, Apache child messed up afterwards
Hi, Did anybody ever see a message like this in the error log after an "internal server error"? [error] Undefined subroutine &Apache::lonhomework::handler called at /dev/null line 65535. No further entries. lonhomework is the mod_perl handler attached to a URL, and is called directly. This happens intermittently and seemingly at random; however, after this happened once, that Apache child is messed up and will do this again and again when hit - so depending on which child happens to answer, you get the correct reply or another 500. Distributions: Red Hat Linux release 6.2 (Zoot) Kernel 2.2.16-3smp on a 2-processor i686 [www@s10 www]$ rpm -q mod_perl mod_perl-1.23-3 [www@s10 www]$ rpm -q perl perl-5.00503-10 [www@s10 www]$ rpm -q apache apache-1.3.14-2.6.2 Thanks to all in advance! - Gerd. begin:vcard n:Kortemeyer;Gerd tel;fax:(517) 432-2175 tel;work:(517) 432-5468 x-mozilla-html:TRUE url:http://www.lite.msu.edu/kortemeyer/ org:Michigan State University;LITE Lab adr:;;123 North Kedzie Labs;East Lansing;Michigan;48824;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Instructional Technology Specialist x-mozilla-cpt:;3 fn:Gerd Kortemeyer end:vcard
Re: the edge of chaos (URL correction)
My bad. it is www.dslreports.com/front/example.gif Sorry for those curious enough to check the URL out. On Thu, Jan 04, 2001 at 06:10:09PM -0500, Rick Myers wrote: > On Jan 04, 2001 at 17:55:54 -0500, Justin twiddled the keys to say: > > > > If you want to see what happens to actual output when this > > happens, check this gif: > >http://www.dslreports.com/front/eth0-day.gif > > You sure about this URL? I get a 404... > > Rick Myers[EMAIL PROTECTED] > > The Feynman Problem 1) Write down the problem. > Solving Algorithm 2) Think real hard. > 3) Write down the answer.
Re: Newbie cookie question
Problem Solved ... ;) (yes I am an idiot, but keep that under your hat) I had the Apache::AuthCookieDBI's PerlSetVar WhatEverDomain variable set to PerlSetVar WhatEverDomain jeff.foo.com then I would make my request to http://localhost/LOGIN and the domain check would fail. That is why the cookie would not get set. see http://developer.netscape.com:80/docs/manuals/js/client/jsref/cookies.htm#1003254 Determining a Valid Cookie Jeff On Fri, Jan 05, 2001 at 03:52:47PM -0500, Geoffrey Young wrote: > > > > -Original Message- > > From: James Hall [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 05, 2001 3:23 PM > > To: [EMAIL PROTECTED] > > Subject: Newbie cookie question > > > > Now that I have mod_perl installed I cannot pass any cookies > > like I used to. > > I have not changed any scripts [yet] and all use DBI connections to a > > postgres DB. > > > > a code snippet of how you set your cookies would be most helpful... > > be sure to check your outbound and inbound headers (either using telnet or > CPAN modules such as Apache::DumpHeaders or Apache::DebugInfo) to see what > is going on > > do you have PerlSendHeaders On? > > --Geoff Thanks, Jeff --- | "0201: Keyboard Error. Press F1 to continue." | | -- IBM PC-XT Rom, 1982 | --- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
RE: Newbie cookie question
On Fri, 5 Jan 2001, James Hall wrote:
> [snip]
> $user=$query->param('login');
> $password=$query->param('pass');
Okay, there's your problem. You may want to try it this way:
use CGI::Cookie;
...
my %cookies = CGI::Cookie->parse($r->header_in('Cookie')):
my $user = $cookies{'login'};
my $password = $cookies{'pass'};
For more info on how to work with cookies in mod_perl, check the eagle
book. Also note that if you're going to do a redirect and set cookies at
the same time, you have to put the cookies into $r->err_header, since
$r->header doesn't get sent for "error" conditions like redirects.
HTH,
Steve
Re: DBI
There are two components to DBI. The perl module is required for database access, but the Apache DBI module is not. Although you really should use the Apache DBI module to maintain persistent connections to your database. Whether or not you use mod_perl is irrelevant. Joe Grastara wrote: > > I have a question concerning database access under mod_perl. > Can the stardard DBI.pm module be use with mod_perl or does the > Apache::DBI module have to be used instead? > > Thanks in advance for any help. > > Joe Grastara > Project Assistant > Digital Media Center > The Skirball Institute Of Biomolecular Medicine > New York University Medical Center > 540 First Ave., New York City, NY 10016 USA > [EMAIL PROTECTED] > http://www.med.nyu.edu/graphics -- www.RentZone.org
DBI
I have a question concerning database access under mod_perl. Can the stardard DBI.pm module be use with mod_perl or does the Apache::DBI module have to be used instead? Thanks in advance for any help. Joe Grastara Project Assistant Digital Media Center The Skirball Institute Of Biomolecular Medicine New York University Medical Center 540 First Ave., New York City, NY 10016 USA [EMAIL PROTECTED] http://www.med.nyu.edu/graphics
Re: perl calendar application
> functionality. WebTrend and Calcium are decent, but cost $400 for our > situation and any modifications I make would be unsharable. (This > presumes that their source code is even legible and in any shape to hack > on.) Am I totally missing something? Why not just write one to suite your needs? If you want one so tightly integrated to your other products, it's almost always better to custom write it yourself. Or hack up a freeware version. Jim -- Jim Serio - [EMAIL PROTECTED] Producer, World of Coasters
of ports and protocols and redirection...
Alright, I realize this is possibly a silly question, and apologize in advance, *but*. Our company issues it's own digicerts, and our site allows free access to anyone with one of those. We allow free access to anybody in a core "public" area, regardless. Currently I'm using an external redirect in the PerlPostReadRequestHandler if someone tries to hit a secured page on the nonsecure HTTP protocol. I'm not using front/back end servers; it's a reasonably small intranet site behind a firewall. Is that reasonable? Or would there be some vastly better way with mod_rewrite or something? Thanks, all. P. __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/
RE: Newbie cookie question
>a code snippet of how you set your cookies would be most helpful...
My apologies : )
[snip]
$user=$query->param('login');
$password=$query->param('pass');
$dbname="rspde";
$dbh=DBI->connect("dbi:Pg:dbname=$dbname",$user,$password) ||
sendto_main();
$page="main";
$group=check_permissions($user,$password);
$username=get_username($user,$password);
$fname=get_fname($user,$password);
$cookie1=$query->cookie(-name=>'login',
-value=>$user);
$cookie2=$query->cookie(-name=>'pass',
-value=>$password);
print $query->header(-cookie=>[$cookie1,$cookie2]);
print $query ->start_html
(
>do you have PerlSendHeaders On?
PerlSendHeader is ON,
>CPAN modules such as Apache::DumpHeaders or Apache::DebugInfo
I have not used Apache::DumpHeaders or Apache::DebugInfo ... YET
Thanks for the response!
Jim
>-Original Message-
>From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 05, 2001 2:53 PM
>To: 'James Hall'; [EMAIL PROTECTED]
>Subject: RE: Newbie cookie question
>
>
>
>
>> -Original Message-
>> From: James Hall [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, January 05, 2001 3:23 PM
>> To: [EMAIL PROTECTED]
>> Subject: Newbie cookie question
>>
>> Now that I have mod_perl installed I cannot pass any cookies
>> like I used to.
>> I have not changed any scripts [yet] and all use DBI connections to a
>> postgres DB.
>>
>
>a code snippet of how you set your cookies would be most helpful...
>
>be sure to check your outbound and inbound headers (either
>using telnet or
>CPAN modules such as Apache::DumpHeaders or Apache::DebugInfo)
>to see what
>is going on
>
>do you have PerlSendHeaders On?
>
>--Geoff
>
Re: Installing mod_perl-1.24_01 w/o super user and with global perl
> No, I know how to use the modules in my home dir well enough. I don't see where you set PREFIX=/home/eedalf/lib/perl per perlfaq8. Are you sure you read it? I've successfully installed modperl into my own module dir on a NTT/Verio/Iserver FreeBSD box using the system's Perl for quota reasons. John [EMAIL PROTECTED]
perl calendar application
I've looked around the web for perl-based calendar applications for several hours. There are a significant number out there -- I've personally checked out a dozen, but they are generally pretty pathetic. Even most of the ones you can pay for are ugly and have very limited functionality. WebTrend and Calcium are decent, but cost $400 for our situation and any modifications I make would be unsharable. (This presumes that their source code is even legible and in any shape to hack on.) Am I totally missing something? More generally, does anybody have a page of mod_perl business applications? Even more generally, are there any mod_perl applications out there? Neither modperl.org and take23 had much I could find. modperl.org had a page of 'products' that listed some modules, but nothing that I would call an end-user application. I think some of the free web mail programs (?atmail) and forum packages use or can use mod_perl, but how would anybody know that from looking at any of the modperl sites? This is yet another area where the legions of PHP developers are whooping up on us and that's rather depressing. I personally think PHP sucks as a language and I'd rather not have it running on my servers. I certainly don't want to be stuck hacking PHP to add features or fix bugs. But perl folks don't seem to be churning out as many nice SQL-enabled web applications. (And I'd really like to get off Windows for my calendar.) BTW - One notable exception that looks neat that I saw on the mysql mailing list today is maccess: http://www.meopta.com/products/software/maccess/ But it's not aimed at end users. Sigh. -- Those who cannot remember the past are doomed to buy Microsoft products.
RE: mod_perl 1.24_01 Cookie Problem..?? Was: Apache::AuthCookieDBI BEGIN problems...??
> -Original Message- > From: Jeff Sheffield [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 05, 2001 3:48 PM > To: Jacob Davies > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; James Hall > Subject: mod_perl 1.24_01 Cookie Problem..?? Was: > Apache::AuthCookieDBI > BEGIN problems...?? > [snip] > > >I looked through the guide and searched the maillist archive but did > >not find much info to help with this. > >I also tried to install Apache::AuthCookieDBI, but documentation is > >very limited for that and never could get it right. > and that got me to thinking maby this is a mod_perl 1.24_01 problem. > because I am experiencing the same sort of thing. not likely - I use 1.24_01 and Apache::AuthCookie without incident try checking your headers manually as I suggested to James... --Geoff > > Jeff >
RE: Newbie cookie question
> -Original Message- > From: James Hall [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 05, 2001 3:23 PM > To: [EMAIL PROTECTED] > Subject: Newbie cookie question > > Now that I have mod_perl installed I cannot pass any cookies > like I used to. > I have not changed any scripts [yet] and all use DBI connections to a > postgres DB. > a code snippet of how you set your cookies would be most helpful... be sure to check your outbound and inbound headers (either using telnet or CPAN modules such as Apache::DumpHeaders or Apache::DebugInfo) to see what is going on do you have PerlSendHeaders On? --Geoff
Newbie cookie question
Hello, I recently installed mod_perl 1.24_01 and everything is fine except cookies. Specifically, my perl scripts before mod_perl would pass a cookie back and forth with the users name and password - so that each script, when called, would check for the cookie to see if the user is logged in and if not redirect to a login page, if they are logged in then display the requested page. Now that I have mod_perl installed I cannot pass any cookies like I used to. I have not changed any scripts [yet] and all use DBI connections to a postgres DB. I looked through the guide and searched the maillist archive but did not find much info to help with this. I also tried to install Apache::AuthCookieDBI, but documentation is very limited for that and never could get it right. Any help on this is greatly appreciated! Jim
Re: [OT] Rewrite arguments?
Hi there, Didn't see a reply to this yet... On Thu, 4 Jan 2001, Les Mikesell wrote: > This may or may not be a mod_perl question: Probably not :) > I want to change the way an existing request is handled and it can be done > by making a proxy request to a different host but the argument list must > be slightly different.It is something that a regexp substitution can > handle and I'd prefer for the front-end server to do it via mod_rewrite > but I can't see any way to change the existing arguments via RewriteRules. I don't exactly understand your problem, but from what I can see you should be able to do what you want with mod_rewrite if you just use a regexp which contains a question mark. Have I missed something? Does this extract from the docs help? -- One more note: You can even create URLs in the substitution string containing a query string part. Just use a question mark inside the substitution string to indicate that the following stuff should be re-injected into the QUERY_STRING. When you want to erase an existing query string, end the substitution string with just the question mark. Note: There is a special feature: When you prefix a substitution field with http://thishost[:thisport] then mod_rewrite automatically strips it out. This auto-reduction on implicit external redirect URLs is a useful and important feature when used in combination with a mapping-function which generates the hostname part. Have a look at the first example in the example section below to understand this. -- 73, Ged.
Re: mod_perl-1.24 / apache-1.3.14 problem
u need mod_perl-1.24_01 for apache-1.3.14
u might have saved yourself some patching :-)
Mike Hanafey wrote:
> The httpd.h file in apache-1.3.14 has apparently changed. I hacked the
> following changes to mod_perl-1.24 to fix things (it's the same change
> in two files). Without the change Makefile.PL was picking up the wrong
> apache source (even though I have it the source explicitly), and the
> "src.t" test fails on make test.
>
> >>>% diff -c ./Makefile.PL.orig ./Makefile.PL >| /tmp/tmp
> *** ./Makefile.PL.orig Sun May 14 20:07:58 2000
> --- ./Makefile.PL Wed Jan 3 15:03:16 2001
> ***
> *** 1494,1504
> my($server, $version, $rest);
> my($fserver, $fversion, $frest);
> my($string, $extra, @vers);
> while(<$fh>) {
> next unless /^#define/;
> ! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
> ! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
> ! chomp($string = $_);
>
> #print STDERR "Examining SERVER_VERSION '$string'...";
> #could be something like:
> --- 1494,1512
> my($server, $version, $rest);
> my($fserver, $fversion, $frest);
> my($string, $extra, @vers);
> + my($sbp, $sbv);
> while(<$fh>) {
> next unless /^#define/;
> ! m/SERVER_BASEPRODUCT\s+"(.+)"/ and $sbp = $1;
> ! m/SERVER_BASEREVISION\s+"(.+)"/ and $sbv = $1;
> ! if ($sbp && $sbv) {
> ! # Apache 1.3.14
> ! $string = "$sbp/$sbv";
> ! } else {
> ! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
> ! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
> ! chomp($string = $_);
> ! }
>
> #print STDERR "Examining SERVER_VERSION '$string'...";
> #could be something like:
>
>
> >>>% diff -c ./lib/Apache/src.pm.orig ./lib/Apache/src.pm >| /tmp/tmp
> *** ./lib/Apache/src.pm.origFri Mar 31 14:05:24 2000
> --- ./lib/Apache/src.pm Wed Jan 3 16:10:19 2001
> ***
> *** 209,220
> my($server, $version, $rest);
> my($fserver, $fversion, $frest);
> my($string, $extra, @vers);
>
> while(<$fh>) {
> next unless /^#define/;
> ! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
> ! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
> ! chomp($string = $_);
>
> #print STDERR "Examining SERVER_VERSION '$string'...";
> #could be something like:
> --- 209,228
> my($server, $version, $rest);
> my($fserver, $fversion, $frest);
> my($string, $extra, @vers);
> + my($sbp, $sbv);
>
> while(<$fh>) {
> next unless /^#define/;
> ! m/SERVER_BASEPRODUCT\s+"(.+)"/ and $sbp = $1;
> ! m/SERVER_BASEREVISION\s+"(.+)"/ and $sbv = $1;
> ! if ($sbp && $sbv) {
> ! # Apache 1.3.14
> ! $string = "$sbp/$sbv";
> ! } else {
> ! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
> ! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
> ! chomp($string = $_);
> ! }
>
> #print STDERR "Examining SERVER_VERSION '$string'...";
> #could be something like:
>
> Mike Hanafey
> DuPont Ag Products |
> Delaware Technology Park, Suite 200/206 |
> 1 Innovation Way, PO BOX 6104 |
> Newark, DE 19714-6104 |
> Email: [EMAIL PROTECTED] Phone: (302)631-2608 Fax: (302)631-2607 ++
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: the edge of chaos
> "J" == Justin <[EMAIL PROTECTED]> writes: J> I received a helpful recommendation to look into "lingerd" ... J> that would seem one approach to solve this issue.. but a J> lingerd setup is quite different from popular recommendations. I think that's mostly because lingerd is so new. I'm sure as people experiment with it we will see it incorporated into the docs and recommended setups if it holds up.
Re: Javascript - just say no(t required)
hi, Seems to me the only reasonable usage for cookies that does not seem to be abuse.org is as a temporary ticket granting system.. so the next time you want to get a byte you need a ticket to goto the smorg.. Best Regards - [EMAIL PROTECTED]
Re: Javascript - just say no(t required)
> "Gunther" == Gunther Birznieks <[EMAIL PROTECTED]> writes: Gunther> There's a lot of similar FUD about using cookies (not accepted on Gunther> PDAs, people scared of them, etc). Personally, I don't like to program Gunther> using cookies and I have my browser explicitly warn me of the cookie Gunther> before accepting (which does slow down my browsing experience but is Gunther> most interesting),, but the reality is that shedloads of sites use Gunther> them to enhance the user experience but don't make it a problem if Gunther> they don't go and use them. I'm fine with requiring and using cookies for short-term session management, but for long term authentication, they presume "one user == one browser", and that's patently false. If you must use them for long term identification, make it very clear that I'm "logged in", and give me a quick way to "log out", and let me "log in" from a different browser, and automatically "log me out" after 4 hours or so in case I forget. :) And don't do that merely by browser cookie expiration... make the server distrust any cookie after that time, which means you have to generate a unique cookie on each login. Gunther> Speaking of which, I guess the non-use of Cookies and Gunther> JavaScript would make a great NY Resolution... What does New York have to do with it? :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: the edge of chaos
- Original Message - From: "siberian" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 04, 2001 11:41 PM Subject: Re: the edge of chaos > On this thread here is a question. > > Given a scenario with two machines serving web requests. > > Is it better to have 1 machine doing proxy and 1 machine doing mod perl or > is it generally better to have each machine running a proxy and a mod > perl? > > Lame question, I've never benchmarked differences, just curious what some > of you think. I haven't done any real testing either, although I now have a site spread over 4 different machines. My approach was to start by moving the slowest mod_perl programs to a different backend-only box, then moving more to somewhat balance the load, then moving the sql server off to a different box. The 4th box is actually the front end for several smaller sites plus the backend for a few jobs from the main site. The machines all have copies of all the software so a slight reconfiguration could allow running without any one of them at slightly less capacity. Right now everything is controlled by mod_rewrite on the front-end box but the next update is going to be to put a hardware load balancer in front of them. Without hard numbers, I would guess that running the front/back on the same box is slightly faster at lower loads, but completely splitting front/back ends would handle a slightly higher load before melting down due to a little better memory sharing and disk cache handling where each box only runs one version. Les Mikesell [EMAIL PROTECTED]
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory
> > > Are the speedycgi+Apache processes smaller than the mod_perl > > > processes? If not, the maximum number of concurrent requests you can > > > handle on a given box is going to be the same. > > > > The size of the httpds running mod_speedycgi, plus the size of speedycgi > > perl processes is significantly smaller than the total size of the httpd's > > running mod_perl. > > That would be true if you only ran one mod_perl'd httpd, but can you > give a better comparison to the usual setup for a busy site where > you run a non-mod_perl lightweight front end and let mod_rewrite > decide what is proxied through to the larger mod_perl'd backend, > letting apache decide how many backends you need to have > running? The fundamental differences would remain the same - even in the mod_perl backend, the requests will be spread out over all the httpd's that are running, whereas speedycgi would tend to use fewer perl interpreters to handle the same load. But with this setup, the mod_perl backend could probably be set to run fewer httpds because it doesn't have to wait on slow clients. And the fewer httpd's you run with mod_perl the smaller your total memory. > > The reason for this is that only a handful of perl processes are required by > > speedycgi to handle the same load, whereas mod_perl uses a perl interpreter > > in all of the httpds. > > I always see at least a 10-1 ratio of front-to-back end httpd's when serving > over the internet. One effect that is difficult to benchmark is that clients > connecting over the internet are often slow and will hold up the process > that is delivering the data even though the processing has been completed. > The proxy approach provides some buffering and allows the backend > to move on more quickly. Does speedycgi do the same? There are plans to make it so that SpeedyCGI does more buffering of the output in memory, perhaps eliminating the need for caching frontend webserver. It works now only for the "speedy" binary (not mod_speedycgi) if you set the BufsizGet value high enough. Of course you could add a caching webserver in front of the SpeedyCGI server just like you do with mod_perl now. So yes you can do the same with speedycgi now.
Re: seg faults/bus errors
> On Wed, 3 Jan 2001, stujin wrote: > > > I work on a high-traffic site that uses apache/mod_perl, and we're > > seeing some occaisional segmentation faults and bus errors in our > > apache error logs. > We had similar problems, caused by calls to $r->finfo in HTML::Mason, once we removed these the problems went away. The latest version of Mason, no longer uses this method. Mark.
Re: seg faults/bus errors
Hi there, I've seen this post twice now with no response so I thought I'd throw in my 0.02 although I'm not sure it's worth even that much. On Wed, 3 Jan 2001, stujin wrote: > I work on a high-traffic site that uses apache/mod_perl, and we're > seeing some occaisional segmentation faults and bus errors in our > apache error logs. Did you build static? If not I'd try that (especially on Solaris:). 73, Ged.
mod_perl-1.24 / apache-1.3.14 problem
The httpd.h file in apache-1.3.14 has apparently changed. I hacked the
following changes to mod_perl-1.24 to fix things (it's the same change
in two files). Without the change Makefile.PL was picking up the wrong
apache source (even though I have it the source explicitly), and the
"src.t" test fails on make test.
>>>% diff -c ./Makefile.PL.orig ./Makefile.PL >| /tmp/tmp
*** ./Makefile.PL.orig Sun May 14 20:07:58 2000
--- ./Makefile.PL Wed Jan 3 15:03:16 2001
***
*** 1494,1504
my($server, $version, $rest);
my($fserver, $fversion, $frest);
my($string, $extra, @vers);
while(<$fh>) {
next unless /^#define/;
! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
! chomp($string = $_);
#print STDERR "Examining SERVER_VERSION '$string'...";
#could be something like:
--- 1494,1512
my($server, $version, $rest);
my($fserver, $fversion, $frest);
my($string, $extra, @vers);
+ my($sbp, $sbv);
while(<$fh>) {
next unless /^#define/;
! m/SERVER_BASEPRODUCT\s+"(.+)"/ and $sbp = $1;
! m/SERVER_BASEREVISION\s+"(.+)"/ and $sbv = $1;
! if ($sbp && $sbv) {
! # Apache 1.3.14
! $string = "$sbp/$sbv";
! } else {
! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
! chomp($string = $_);
! }
#print STDERR "Examining SERVER_VERSION '$string'...";
#could be something like:
>>>% diff -c ./lib/Apache/src.pm.orig ./lib/Apache/src.pm >| /tmp/tmp
*** ./lib/Apache/src.pm.origFri Mar 31 14:05:24 2000
--- ./lib/Apache/src.pm Wed Jan 3 16:10:19 2001
***
*** 209,220
my($server, $version, $rest);
my($fserver, $fversion, $frest);
my($string, $extra, @vers);
while(<$fh>) {
next unless /^#define/;
! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
! chomp($string = $_);
#print STDERR "Examining SERVER_VERSION '$string'...";
#could be something like:
--- 209,228
my($server, $version, $rest);
my($fserver, $fversion, $frest);
my($string, $extra, @vers);
+ my($sbp, $sbv);
while(<$fh>) {
next unless /^#define/;
! m/SERVER_BASEPRODUCT\s+"(.+)"/ and $sbp = $1;
! m/SERVER_BASEREVISION\s+"(.+)"/ and $sbv = $1;
! if ($sbp && $sbv) {
! # Apache 1.3.14
! $string = "$sbp/$sbv";
! } else {
! s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
! next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
! chomp($string = $_);
! }
#print STDERR "Examining SERVER_VERSION '$string'...";
#could be something like:
Mike Hanafey
DuPont Ag Products |
Delaware Technology Park, Suite 200/206 |
1 Innovation Way, PO BOX 6104 |
Newark, DE 19714-6104 |
Email: [EMAIL PROTECTED] Phone: (302)631-2608 Fax: (302)631-2607 ++
PerlRun bug
Hi all,
There is a bug in PerlRun.pm that causes internal server error
if PerlRun handler is called for inexistent file. I think that
problem was introduced by this change
=item 1.24_01 - October 10, 2000
.
change Apache::PerlRun's Apache class relationship from is-a to has-a
There are a couple of places left where $pr->{r}->_some_method_() should be
called instead of $pr->_some_method_(). One of them is already noted -- call
to uri() in sub error_check.
Here is the patch:
---
--- old/PerlRun.pm Thu Sep 28 23:59:36 2000
+++ new/PerlRun.pm Thu Jan 04 16:10:27 2001
@@ -50,7 +50,7 @@
$pr->{'mtime'} = -M _;
return wantarray ? (OK, $pr->{'mtime'}) : OK;
}
-$pr->log_error("$filename not found or unable to stat");
+$r->log_error("$filename not found or unable to stat");
return NOT_FOUND;
}
@@ -209,7 +209,7 @@
my $pr = shift;
if ($@ and substr($@,0,4) ne " at ") {
$pr->{r}->log_error("PerlRun: `$@'");
-$@{$pr->uri} = $@;
+$@{$pr->{r}->uri} = $@;
$@ = ''; #XXX fix me, if we don't do this Apache::exit() breaks
return SERVER_ERROR;
}
---
-- Alexander
seg faults/bus errors
Hi, I work on a high-traffic site that uses apache/mod_perl, and we're seeing some occaisional segmentation faults and bus errors in our apache error logs. These errors sometimes result in the entire apache process group going down, though it seems to me that the problems originate within one of apache's child processes (maybe shared memory is getting corrupted somehow?). I've searched through the archive of this list for similar situations, and I found a lot of questions about seg faults, but none quite matching our problem. We installed some signal handlers in our perl code that trap SIGSEGV and SIGBUS and then dump a perl stack trace to a log file (see below). Using this stack infomation, we can track the point of failure to a call to perl's "fork()" inside the IPC::Open3 standard module. Since it seems very unlikely that fork() is broken, we're speculating that there's some funny business going on prior to the fork that's putting the process into an unstable state which prevents it from forking successfully. Due to a lot of sloppy, pre-existing Perl code, we're using PerlRun (not Registry) with "PerlRunOnce On" (children die after servicing one hit). Does anyone have any suggestions about what might be going on here? Thanks! Justin Caballero The following are: a backtrace from a core dump, the stack trace from the perl signal handler, and the version information for our environment. - apache1.3.12 mod_perl1.24 - (gdb) where #0 0xe765c in Perl_sv_free () #1 0xd89f4 in Perl_hv_free_ent () #2 0xd8bd8 in Perl_hv_clear () #3 0xd8b3c in Perl_hv_clear () #4 0x10e760 in Perl_pp_fork () #5 0x11b1d0 in Perl_runops_standard () #6 0xa49e8 in perl_call_sv () #7 0xa4490 in perl_call_method () #8 0x2aea8 in perl_call_handler () #9 0x2a6e0 in perl_run_stacked_handlers () #10 0x28da0 in perl_handler () #11 0x6e0f8 in ap_invoke_handler () #12 0x8a8e8 in ap_some_auth_required () #13 0x8a96c in ap_process_request () #14 0x7e3e4 in ap_child_terminate () #15 0x7e770 in ap_child_terminate () #16 0x7ece8 in ap_child_terminate () #17 0x7f54c in ap_child_terminate () #18 0x7fe80 in main () - SIGSEGV caught at: IPC::Open3, /opt/perl-5.005_03/lib/5.00503/IPC/Open3.pm, 102, main::cgi_stack_dump IPC::Open3, /opt/perl-5.005_03/lib/5.00503/IPC/Open3.pm, 150, IPC::Open3::xfork IPC::Open2, /opt/perl-5.005_03/lib/5.00503/IPC/Open2.pm, 91, IPC::Open3::_open3 Cyxsub, /prod/APP/vobs/ssp/cgi-bin/Cyxsub.pm, 69, IPC::Open2::open2 Cyxsub, /prod/APP/vobs/ssp/cgi-bin/Cyxsub.pm, 152, Cyxsub::sd_connect main, /prod/ssp_2.8_mp_prod_sv.001212/vobs/ssp_perl/cgi-bin/hy_inquiry_zc.pl, 43, Cyxsub::xs_ods_main main, /prod/ssp_2.8_mp_prod_sv.001212/vobs/ssp_perl/cgi-bin/cp_pers-io_zc.pl, 39, main::obtain_data main, /prod/APP/vobs/ssp/cgi-bin/cp_pers_ub.pl, 285, main::cp_pers_io_zc_get_data_from_host main, /prod/APP/vobs/ssp/cgi-bin/cp_pers_ub.pl, 208, main::cp_pers_ub_online_update main, /prod/APP/vobs/ssp/cgi-bin/cp_pers_ub.pl, 70, main::cp_pers_ub_update_ok main, /prod/APP/vobs/ssp/cgi-bin/cp_pers_ub.pl, 39, main::cp_pers_ub_main Apache::PerlRun, /opt/perl-5.005_03/lib/site_perl/5.005/sun4-solaris/Apache/PerlRun.pm, 122, (eval) Apache::PerlRun, /opt/perl-5.005_03/lib/site_perl/5.005/sun4-solaris/Apache/PerlRun.pm, 296, Apache::PerlRun::compile Apache::Constants, /prod/ssp_2.8_mp_prod_sv.001212/vobs/ssp_perl/cgi-bin/opa_common_zc.pl, 0, Apache::PerlRun::handler Apache::Constants, /prod/ssp_2.8_mp_prod_sv.001212/vobs/ssp_perl/cgi-bin/opa_common_zc.pl, 0, (eval) - > perl -V Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos atlas 5.6 generic_105181-19 sun4u sparc sunw,ultra-250 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='gcc -B/usr/ccs/bin/', optimize='-O', gccversion=2.95.2 19991024 (release) cppflags='-I/usr/local/include' ccflags ='-I/usr/local/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Built under solaris Compiled at Jul 11 2000 15:12:53 @INC: /opt/perl5.005_03-gcc/lib/5.00503/sun4-solaris /opt/perl5.005_03-gcc/lib/5.00503 /o
