Re: mod_perl SSL compression: Apache-Dynazip vs mod_gzip?
Hi Nigel, - Original Message - From: "Nigel Hamilton" <> To: <[EMAIL PROTECTED]> Sent: Thursday, October 03, 2002 6:29 PM > ... > However, recently I've needed to use SSL, but I've heard the > combination of mod_gzip and SSL is buggy on some browsers. You are right, there are some known issues about M$IE, which sometimes drops first 2K bytes, when the user "refreshes" content over SSL. The way to work around is the same for all compression approaches: just place 2K blank spaces in the beginning of every your web page (fortunately, they will be compressed very effectively). > I've checked out Apache::DynaGzip and it looks like what I need - > but I'm interested in what other SSL+Compression combinations work best > with mod_perl? There are no compression features for SSL on server side. Just the encryption should be done over the (dynamically) compressed file/stream. Apache::Dynagzip could be really helpful if you use mod_perl-enabled Apache to generate content on-the-fly (see Web Content Compression FAQ, attached in M$ Word format). > Here is a url that discusses compression options: > > http://www.innerjoin.org/apache-compression/ I like it. Thanks, Slava Web Content Compression FAQ-rev7.doc Description: MS-Word document
Re: Re: Defaulting to default-handler from custom handler
Yup that fixed it, setting the handler via $r->handler('cgi-script') in a FixupHandler
works. The table in the mod_perl cookbook (pg452) says is all. I must have overlooked
that bit of information while I was banging my head on the my desk trying to get this
to work.
Thanks for the help and the book too ;)
-Carlos
>
> From: Geoffrey Young <[EMAIL PROTECTED]>
> Date: 2002/10/03 Thu AM 07:11:29 CDT
> To: Carlos Ramirez <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> Subject: Re: Defaulting to default-handler from custom handler
>
>
> >
> > All four cases result in the Perl code being displayed instead of the
> > script being executed? If a location is defined as a ScriptAlias, then
> > is the default-handler == perl-script? and would returning DECLINED
> > result in mod_cgi handling the request? What am I doing wrong?
>
> perl-script is mod_perl
>
> default-handler is the Apache default (to just send the document)
>
> cgi-script is mod_cgi
>
>
> so, if you want mod_cgi to do it, try
>
> $r->handler('cgi-script');
> return DECLINED;
>
> but I couldn't get that to work from a Registry script, since I
> suspect that it's too late to alter the course of the request via
> $r->handler(). a PerlFixupHandler is generally a good place to alter
> $r->handler() to perhaps you can put your logic there instead.
>
> we talk about $r->handler() a bit in chapter 14 in the Cookbook, and
> 14.1 has a list of modules and their corresponding handler name.
>
> HTH
>
> --Geoff
>
>
>
perl script not reloading
It seems that as I work on my script, Apache doesn't reload it when the script changes on disk. It seems like it's something that I did because it used to. Is there some common well known thing or set of things one can screw up to make this happen? (if so, it should be documented in the mod_perl_traps man page). Michael Grant
Re: [Q][LONG] using IPC::Shareable to cache data, Apache doesnt start
Juan Natera wrote: > The worst of all is that Apache simply doesnt start, and I get no error > message at all. The error might be on the console, or you could try capturing it and writing it to a file. However, I suggest you ditch IPC::Shareable since it's dog slow. Use MLDBM::Sync, Cache::FileCache, IPC::MM, or Cache::Mmap. - Perrin
[Q][LONG] using IPC::Shareable to cache data, Apache doesnt start
Hello everyone,
I am trying to use a IPC::Shareable tied hash to cache some data at the
start of apache from my startup.pl script.
this is my startup.pl
-
$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or
die "GATEWAY_INTERFACE not Perl!";
use Apache::Registry;
use Apache::DBI;
use IPC::Shareable;
use GXV::Abonados;
use strict;
my %GLOBALDATA;
my %options = (
create=> 1,
exclusive => 0,
mode => 0666,
destroy => 1,
);
tie %GLOBALDATA, 'IPC::Shareable', 'GLUE', { %options } ||
die "tie failed\n";
my $gxv = GXV::Abonados->new ||
die "not able to connect to GXV\n";
eval {
%GLOBALDATA = $gxv->paquetes_shared;
};
die "Global data is not accessible: $@" if ($@);
1;
--
The method GXV::Abonados::paquetes_shared() works, I have tried many
forms of recieving (and returning of course) the data (a flat scalar,
arrays, hashes).
If I asign to *GLOBALDATA a short string or number it works, I checked
IPC::Shareable::SHM_BUFSIZ(); and it's more than enough to hold the
return value of $gxv->paquetes_shared;
The worst of all is that Apache simply doesnt start, and I get no error
message at all.
Can someone please give me some insight?
TIA,
Best Regards,
Juan Jose Natera
Re: Response Headers
On Thu, 3 Oct 2002, Paul Simon wrote: > > How do HTTP headers work under Registery::ModPerl? > set up: windows2000 apache2.0.42 mod_perl/1.99_08-dev Perl/v5.8.0 > > I had to comment out the following in the CGI script: > > #print "Expires: " . time2str( time() + 432000 ) . "\n"; > #print "Content-type: text/html\n\n"; > > because it would print out as content to the browser?? > > This is in the conf file: > > Alias /standards/ "C:/Apache2/application/standards2/" > > SetHandler perl-script > PerlResponseHandler ModPerl::Registry > #PerlOptions +ParseHeaders > Options +ExecCGI > > > If somebody could point me in the right direction -> > > Thanks. If you send the headers yourself, as, eg, print "Content-type: text/html\n\n"; in the script, then you should have PerlOptions +ParseHeaders in the relevant section. If you don't send the header yourself, Apache will send one for you, based on, in particular, the DefaultType setting. In this case you shouldn't have PerlOptions +ParseHeaders in that section. As you found, other combinations can lead to a double set of headers sent, resulting in one of them appearing in the browser. -- best regards, randy kobes
Response Headers
How do HTTP headers work under Registery::ModPerl?set up: windows2000 apache2.0.42 mod_perl/1.99_08-dev Perl/v5.8.0 I had to comment out the following in the CGI script: #print "Expires: " . time2str( time() + 432000 ) . "\n";#print "Content-type: text/html\n\n"; because it would print out as content to the browser?? This is in the conf file: Alias /standards/ "C:/Apache2/application/standards2/" SetHandler perl-script PerlResponseHandler ModPerl::Registry #PerlOptions +ParseHeaders Options +ExecCGI If somebody could point me in the right direction -> Thanks.Do you Yahoo!? New DSL Internet Access from SBC & Yahoo!
Re: [mp2.0] wrong crypt behavior
On Fri, 6 Sep 2002 08:23:33 +0200 Toma'? Procha'zka <[EMAIL PROTECTED]> wrote:
> For comparsion of password user entered and password stored in database is
> crypt function used.
>
> Here is the code:
> my $real_pass = $d->[0][0]; # crypted password from database
> my $salt = substr $real_pass,0,2; # salt
> my $test_pass = crypt $sent_pw,$salt; # in $sent_pw is the password user entered
> if ($real_pass eq $test_pass) {
> $r->subprocess_env(REMOTE_USER => $user);
> return OK;
> } else {
> $r->note_basic_auth_failure;
> return AUTH_REQUIRED;
> }
>
> Problem: Sometimes, although user entered correct password, is authentication
> rejected. I tried logging values of $real_pass and $test_pass and they
> differed. When I add line
>
> $r->log_reason("User $user tested (".$real_pass."/".$test_pass.")...","");
>
> just before 'if' statement behavior is most of time correct.
I have also seen this problem. I am using RT [0] and have intermittent
login problems where suddenly crypt() called from mod_perl will start
generating the wrong return values [ i.e., $pass ne crypt($user, $pass) ].
After some period of time the crypt() call will start generating the
correct values again.
Executing the exact same crypt() calls via a command-line
perl -e 'print crypt([string], [string])' generates the expected
(correct) results.
If (in the code run by mod_perl) I replace:
if ($pass eq crypt($user, $pass)) {
with:
$crypt = `perl -e 'print crypt(\"$user\", \"$pass\")'`;
chomp($crypt);
if ($pass eq $crypt) {
Then everything works perfectly, though less quickly and blatantly
insecurely. I have checked the failing $user, $pass and crypt() values
thoroughly for wierdness and compared them to their successful
counterparts. I am 100% convinced that crypt() is returning the wrong
values. Note that the wrong values are consistent (i.e., they are not
random, not changing, just not correct).
My original RT problem report (including voluminous configuration
information, but prior to the isolation of the crypt() issue) can be
found at:
http://lists.fsck.com/pipermail/rt-users/2002-September/010117.html
Question: is crypt() thread-safe? I haven't had a chance to look at
the source but I plan on doing so soon.
A tiny bit more info:
$ strace perl -e 'print crypt("foo", "bar")' 2>&1 | grep crypt
execve("/usr/bin/perl", ["perl", "-e", "print crypt(\"foo\", \"bar\")"], [/* 22 vars
*/]) = 0
open("/lib/libcrypt.so.1", O_RDONLY)= 3
$ ls -al /lib/libcrypt.so.1 /lib/libcrypt-2.2.5.so
lrwxrwxrwx1 root root 17 Sep 23 18:13 /lib/libcrypt.so.1 ->
libcrypt-2.2.5.so
-rw-r--r--1 root root19136 Sep 17 21:50 /lib/libcrypt-2.2.5.so
[0] http://www.bestpractical.com/rt/index.html
Rick
--
http://www.rickbradley.comMUPRN: 812(???F/???F)
| me a line. It's the
random email haiku | only commercial unix
| I've ever liked. Wow.
Re: install/config mod_perl-2(1.99_08)
Randy Kobes <[EMAIL PROTECTED]>wrote: On Thu, 3 Oct 2002, Paul Simon wrote:> > Is there something in the configuration not jiving?> > Windows 2000, Apache 2.0.42, mod_perl-2(1.99_08-dev via ppm)> > In http.conf I have:> Include conf/test.conf> AddHandler cgi-script .cgi> > In test.conf I have:> PerlRequire "C:/Apache2/conf/startup.pl"> > Options +ExecCGI> SetHandler perl-script> PerlResponseHandler ModPerl::Registry> PerlOptions +ParseHeaders> > #ScriptAlias /test/ "C:/Apache2/htdocs/test/"> > startup.pl looks like:> #!C:/Perl/bin/Perl.exe> use Apache2();> use ModPerl::Registry ();> 1;> > Apache starts up. I can see mod_perl loaded in via> server-status. And when I call just the directory /test/, this> what I get in the error log:> > [error] 1932: ModPerl::Registry: C:/Apache2/htdocs/test/ not> found or unable to statThis is OK - you normally don't want a directory listingfor locations that have scripts in them.> If I try to call index.cgi under /test/index.cgi, the page just> hangs. index.cgi works as a straight CGI page. Here it is:> #!C:/Perl/bin/Perl.exe> > print "Content-type: text/plain\n\n";> print "mod_perl 2.0 rocks!\n";> > --- I'll keep trying. Hopefully, there's an easy solution> to this. Thanks.Maybe not easy :) Using perl-5.6.1, and Apache-2.0.42, I foundthe above to also hang ... However, it worked as expected usingthe perl-5.8/Apache2 binary of perl-5.8-win32-bin.tar.gz underftp://theoryx5.uwinnipeg.ca/pub/other/. As there's issues withthreads on Win32 with perl-5.6.1, eventually perl-5.8 will be therecommended Win32 Perl for mod_perl-2; if possible, you may wantto give this a try.-- best regards,randy kobes Almost easy. I have it running now with perl5.8. I'm going to pilot it... Thanks. PaulDo you Yahoo!? New DSL Internet Access from SBC & Yahoo!
Apache::AuthDBI problem
I'm having trouble with the AuthDBI module. If works fine if use require valid-user or require user. But when I try to require group I get this error: couldn't check access. No groups file?: /test/ What am I doing wrong? This is my .htaccess file. AuthName "DBI" AuthType Basic PerlAuthenHandler Apache::AuthDBI::authen PerlAuthenHandler Apache::AuthDBI::authz PerlSetVar Auth_DBI_encrypted off PerlSetVar Auth_DBI_data_source dbi:mysql:database=auth;host=localhost PerlSetVar Auth_DBI_username username PerlSetVar Auth_DBI_password password PerlSetVar Auth_DBI_pwd_table passwd PerlSetVar Auth_DBI_uid_field username PerlSetVar Auth_DBI_pwd_field password PerlSetVar Auth_DBI_grp_table passwd PerlSetVar Auth_DBI_grp_field grp require group test1 Any help would be great. Robert
Backtraces on recurring segfaults on mod_perl-1.27/apache-1.3.26
I've managed to get a couple of backtraces on a segfault problem we've been having for months now. The segfaults occur pretty rarely on the whole, but once a client triggers one on a particular page, they do not stop. The length and content of the request are key in making the segfaults happen. Modifying the cookie or adding characters to the request line causes the segfaults to stop. example (word wrapped): This request will produce a segfault (backtrace in attached gdb1.txt) and about 1/3 of the expected page : nc 192.168.1.20 84 GET /perl/section/entcmpt/ HTTP/1.1 User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux 2.4.18-5) Pragma: no-cache Cache-control: no-cache Accept: text/*, image/jpeg, image/png, image/*, */* Accept-Encoding: x-gzip, gzip, identity Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5 Accept-Language: en Host: 192.168.1.20:84 Cookie: mxstsn=1033666066:19573.19579.19572.19574.19577.19580.19576.19558.19560.19559.19557.19567.19566.19568.19544.19553.19545.19551.19554.19546.19548.19547.19532.19535.19533.19538.19534:0; Apache=192.168.2.1.124921033666065714 Adding a bunch of zeroes to the URI (which does not change the code functionality) causes the page to work correctly: nc 192.168.1.20 84 GET /perl/section/entcmpt/? HTTP/1.1 User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux 2.4.18-5) Pragma: no-cache Cache-control: no-cache Accept: text/*, image/jpeg, image/png, image/*, */* Accept-Encoding: x-gzip, gzip, identity Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5 Accept-Language: en Host: 192.168.1.20:84 Cookie: mxstsn=1033666066:19573.19579.19572.19574.19577.19580.19576.19558.19560.19559.19557.19567.19566.19568.19544.19553.19545.19551.19554.19546.19548.19547.19532.19535.19533.19538.19534:0; Apache=192.168.2.1.124921033666065714 Some info: /usr/apache-perl/bin/httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_so.c mod_setenvif.c mod_php4.c mod_perl.c Please forgive any obvious missing info (i'm not a c programmer). The first backtrace shows the segfault happening in mod_perl_sent_header(), and the second shows it happening in the ap_make_array() which was from Apache::Cookie. I don't have one handy now, but I've also seen it happen in ap_soft_timeout() after an XS_Apache_print (r->server was out of bounds). I've added a third backtrace where r->content_encoding contains the above 'mxstsn' cookie name. Any help would be greatly appreciated. -- -- Daniel Bohling NewsFactor Network [root@proxy dumps]# gdb /usr/apache-perl/bin/httpd core.12510 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/apache-perl/bin/httpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /usr/lib/libmysqlclient.so.10...done. Loaded symbols for /usr/lib/libmysqlclient.so.10 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/i686/libc.so.6...bdone. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/perl5/5.6.1/i386-linux/auto/Data/Dumper/Dumper.so...done. Loaded symbols for /usr/lib/perl5/5.6.1/i386-linux/auto/Data/Dumper/Dumper.so Reading symbols from /usr/lib/perl5/5.6.1/i386-linux/auto/Socket/Socket.so...done. Loaded symbols for /usr/lib/perl5/5.6.1/i386-linux/auto/Socket/Socket.so Reading symbols from /usr/lib/perl5/5.6.1/i386-linux/auto/IO/IO.so...done. Loaded symbols for /usr/lib/perl5/5.6.1/i386-linux/auto/IO/IO.so Read
[OT] Re: asynchronous downloads
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 03, 2002 5:09 PM Subject: Re: asynchronous downloads > > How do I send a file asynchronously? > > > > The classic example is download sites. You click on the file you want and > > it generates a thankyou page for your browser and also sends the file. > > > > So what's the correct way to do this? > > > > Use a refresh META tag on the thank-you page, that points to the > requested file. Look at any download page at SourceForge to see how it > is done. > > Alternatively, you can return a multipart/mixed MIME message with > both documents as the result of the HTTP request. > Actually, that is not defined for HTTP. Although people commonly interchange the Content-Type field defined by HTTP, and that defined by MIME, the two are not interchangable. The closest that HTTP comes to working with multipart fields is the multipart/form-data Content-Type defined in RFC 2388 (http://www.ietf.org/rfc/rfc2388.txt) As it happens, I noticed this a couple of years ago, and am currently planning an I-D which will implement multipart/related HTTP responses. If anyone at all is interested in this, please don't hesitate to contact me about it - BUT, let's keep that off-list, please :-) Issac
mod_perl SSL compression: Apache-Dynazip vs mod_gzip?
Hi, I've been using mod_gzip for the last 18 months and it has worked really well for dynamic pages and static content. However, recently I've needed to use SSL, but I've heard the combination of mod_gzip and SSL is buggy on some browsers. I've checked out Apache::DynaGzip and it looks like what I need - but I'm interested in what other SSL+Compression combinations work best with mod_perl? So here's a little survey ... 1. Are you using http compression with mod_perl? 2. Which compression modules? filters? are you using? 3. Do you also compress SSL content? 4. Do you get bizarre errors on some browsers? 5. Do your pages contain CSS files and .js files? 6. Recommendations? Here is a url that discusses compression options: http://www.innerjoin.org/apache-compression/ Nigel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: Graphics and mod_perl
On Wed, 2 Oct 2002, Justin Luster wrote: > I'm new to mod_perl and I'm really enjoying it. It has really improved > performance. Right now I'm just using Modperl::Registry to speed up > things. I have a question about showing graphics using a Perl Script > and running it through mod_perl. [ ... ] > It seems that the current working directory for the Perl scripts when > run under mod_perl is in the bin directory where Apache.exe is. That behaviour was introduced into Win32 Apache some time back, one reason being, as I understand it, is so that one could double-click on the Apache icon to start it up. > I have considered using absolute paths but even that does not > seem to work correctly with graphics. [ ... ] As Per Einar mentioned in an earlier reply, using absolute server paths is the best solution - generally, for cgi and registry scripts, one should not rely on an assumption of a current working directory. There is a module, FindBin, which reveals the directory of a script, but as explained in the perl-5.8 docs for FindBin, there's some caveats to using it under mod_perl and other persistant Perl environments. -- best regards, randy kobes
RE: install/config mod_perl-2(1.99_08)
On Thu, 3 Oct 2002, Ben Mathews wrote: > You say eventually perl 5.8 will be recommended. Why is it not the > recommended version now? That's really Doug's call, but perhaps one consideration holding back a recommendation of 5.8 on Win32 is that ActiveState won't be making a perl-5.8 binary in the immediate future, and may wait until a 5.8.1 is released (5.8 and 5.6 aren't binary compatable, so this is a major step). And there are some portability things, for example, with unicode - some modules which rely on the way 5.6.1 deals with this need changes with 5.8. > I am developing a windows application currently and started out with > activestate perl 5.6.1, apache 2, and mod_perl 1.99. I ran into a lot > of problems and blamed them on mod_perl because it is still rather new. > Things have progressed smoothly enough using apache versions 1.x and > mod_perl 1.x > > I didn't think of trying perl 5.8, but would be glad to if that is going > to help things. I would like the capabilities that Apache and mod_perl > 2.x give. > > Ben I've found that using 5.8 often is more "stable" than 5.6.1, as far as mod_perl-2 goes - it's definitely worth trying out for development. -- best regards, randy
RE: install/config mod_perl-2(1.99_08)
You say eventually perl 5.8 will be recommended. Why is it not the recommended version now? I am developing a windows application currently and started out with activestate perl 5.6.1, apache 2, and mod_perl 1.99. I ran into a lot of problems and blamed them on mod_perl because it is still rather new. Things have progressed smoothly enough using apache versions 1.x and mod_perl 1.x I didn't think of trying perl 5.8, but would be glad to if that is going to help things. I would like the capabilities that Apache and mod_perl 2.x give. Ben -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 8:30 AM To: Paul Simon Cc: [EMAIL PROTECTED] Subject: Re: install/config mod_perl-2(1.99_08) Maybe not easy :) Using perl-5.6.1, and Apache-2.0.42, I found the above to also hang ... However, it worked as expected using the perl-5.8/Apache2 binary of perl-5.8-win32-bin.tar.gz under ftp://theoryx5.uwinnipeg.ca/pub/other/. As there's issues with threads on Win32 with perl-5.6.1, eventually perl-5.8 will be the recommended Win32 Perl for mod_perl-2; if possible, you may want to give this a try. -- best regards, randy kobes
Re: install/config mod_perl-2(1.99_08)
On Thu, 3 Oct 2002, Paul Simon wrote: > > Is there something in the configuration not jiving? > > Windows 2000, Apache 2.0.42, mod_perl-2(1.99_08-dev via ppm) > > In http.conf I have: > Include conf/test.conf > AddHandler cgi-script .cgi > > In test.conf I have: > PerlRequire "C:/Apache2/conf/startup.pl" > > Options +ExecCGI > SetHandler perl-script > PerlResponseHandler ModPerl::Registry > PerlOptions +ParseHeaders > > #ScriptAlias /test/ "C:/Apache2/htdocs/test/" > > startup.pl looks like: > #!C:/Perl/bin/Perl.exe > use Apache2(); > use ModPerl::Registry (); > 1; > > Apache starts up. I can see mod_perl loaded in via > server-status. And when I call just the directory /test/, this > what I get in the error log: > > [error] 1932: ModPerl::Registry: C:/Apache2/htdocs/test/ not > found or unable to stat This is OK - you normally don't want a directory listing for locations that have scripts in them. > If I try to call index.cgi under /test/index.cgi, the page just > hangs. index.cgi works as a straight CGI page. Here it is: > #!C:/Perl/bin/Perl.exe > > print "Content-type: text/plain\n\n"; > print "mod_perl 2.0 rocks!\n"; > > --- I'll keep trying. Hopefully, there's an easy solution > to this. Thanks. Maybe not easy :) Using perl-5.6.1, and Apache-2.0.42, I found the above to also hang ... However, it worked as expected using the perl-5.8/Apache2 binary of perl-5.8-win32-bin.tar.gz under ftp://theoryx5.uwinnipeg.ca/pub/other/. As there's issues with threads on Win32 with perl-5.6.1, eventually perl-5.8 will be the recommended Win32 Perl for mod_perl-2; if possible, you may want to give this a try. -- best regards, randy kobes
Re: Dynamlcally loading modules at run-time
Hi Jochen, I'd recommend having a read of this http://perl.apache.org/docs/1.0/guide/performance.html#Sharing_Memory Not sure how much it applies to your situation, but basically, unless the different modules are very large and rarely used you really want to load them all at server startup. That way your server processes will be sharing the majority of your code and memory use will be optimised increasing the number of server processes you'll be able to run. Loading more modules after startup will increase the size of each process independantly, increasing your overall memory use. cheers, J Jochen Lillich wrote: > Hi, > > I'm writing my first mod_perl handler. I'd like to make the handler some > kind of dispatcher that dynamically loads certain modules depending on > the URI called: > > /foo/index => require foo; $result = foo::index(); > /foo/other => require foo; $result = foo::other(); > /bar/index => require bar; $result = bar::index(); > > I'd like to ask for your advice there. Is this a clever way to go in > the first place? And how would i best code this concept? Or is there a > better way to reach a modular structure in a big web application? > > Best regards, > > Jochen > > . >
Re: Dynamlcally loading modules at run-time
Jochen Lillich wrote: > Hi, > > I'm writing my first mod_perl handler. I'd like to make the handler some > kind of dispatcher that dynamically loads certain modules depending on > the URI called: > > /foo/index => require foo; $result = foo::index(); > /foo/other => require foo; $result = foo::other(); > /bar/index => require bar; $result = bar::index(); look into Apache::Dispatch. I haven't touched the code in a while, but it does what you're seeking. > > I'd like to ask for your advice there. Is this a clever way to go in > the first place? And how would i best code this concept? Or is there a > better way to reach a modular structure in a big web application? probably :) try looking at things like Mason, Embperl, Template Toolkit, Apache::ASP... --Geoff
Dynamlcally loading modules at run-time
Hi, I'm writing my first mod_perl handler. I'd like to make the handler some kind of dispatcher that dynamically loads certain modules depending on the URI called: /foo/index => require foo; $result = foo::index(); /foo/other => require foo; $result = foo::other(); /bar/index => require bar; $result = bar::index(); I'd like to ask for your advice there. Is this a clever way to go in the first place? And how would i best code this concept? Or is there a better way to reach a modular structure in a big web application? Best regards, Jochen
RE: Easy internal redirect question
After further review, the problem was CGI.pm. CGI.pm doesn't appear to get
'reset' on an internal_redirect (I'm not familiar with CGI's support for
mod_perl, so maybe this should have been obvious!) so it was still holding
the old parameter values. A quick install of Apache::Request and a call to
$r->param('task') give much better results. CGI was a remnant from our
pre-mod_perl days and I've been meaning to get rid of it for a while.
Thanks,
Fran
how to detect a broken connection using mod_proxy
hi all, i am running standard setup with one plain apache with mod_proxy and a mod_perl apache to which all mod_perl requests are directed by the proxy module. i want to be able to detect when the client connection breaks but all standard recipes like the one mentioned in p.147 of the cookbook don't work due the use of mod_proxy. does anyone know of a trick to detect when the connection is broken in such a scenario so that i can free up cpu resources? (i have a set of 4 heavy sql stm's. after each one of them i would like to check if the client is still there so that i will proceed to the next one or just return OK and forget about the request). many thanks, giorgos
Re: asynchronous downloads
I think many sites use the meta refresh html tag. i.e. ... ... Netscape has a complete reference on this at http://developer.netscape.com/docs/manuals/htmlguid/tags3.htm#1697602 You could probably also set a refresh header. I hope this helps. -kb Andrew G. Hammond wrote: > How do I send a file asynchronously? > > The classic example is download sites. You click on the file you want and > it generates a thankyou page for your browser and also sends the file. > > So what's the correct way to do this? >
Re: asynchronous downloads
> How do I send a file asynchronously? > > The classic example is download sites. You click on the file you want and > it generates a thankyou page for your browser and also sends the file. > > So what's the correct way to do this? > Use a refresh META tag on the thank-you page, that points to the requested file. Look at any download page at SourceForge to see how it is done. Alternatively, you can return a multipart/mixed MIME message with both documents as the result of the HTTP request. -- Dominique QUATRAVAUX Ingénieur développeur senior 01 44 42 00 27 IDEALX
asynchronous downloads
How do I send a file asynchronously? The classic example is download sites. You click on the file you want and it generates a thankyou page for your browser and also sends the file. So what's the correct way to do this?
Re: [BUG] Losing GET/POST-data
Hi Hakan,
CGI::Minimal has a "truncate" function that picks up invalid CGI
data ... this may help.
Nigel
> On Wed, 2 Oct 2002, Wes Cravens wrote:
>
> > On 02 Oct 2002 15:23 GMT I wrote:
> >
> > >
> > > Hi!
> > >
> > > We're developing a perl module for apache/mod_perl, but have encountered a
> > > really strange problem.
> > >
> > > After 'a while' we seem to lose the data sent to the apache-server, at
> > > least it never reaches our module.
> >
> >
> >
> > > Recently we switched from using the standard Apache request-object to
> > > using the Apache::Request one, for the added functionality, but this has
> > > not had any effect at all as far as we can tell, and the bug keeps
> > > happening...
> >
> > I ran into a problem that the param parts of a request were flushed
> > when read for the first time... so if you lose them (don't store them)
> > then you cannot access them again.
>
> Yep, noticed this myself when re-writing it to check the input, should
> have posted this first perhaps, but anyway, this is basically how we
> handle the input:
>
> sub handler($)
> {
> $^W = 1; # gripe about the little things
> my $r = shift;
> my %parm;
>
> if ($r->method() eq 'POST') { %parm = $r->content(); }
> elsif ($r->method() eq 'GET') { %parm = $r->args(); }
>
>
>
> And now, after the re-write with Apache::Request
>
> sub handler($)
> {
> $^W = 1; # gripe about the little things
> my $r = shift;
> my $apr;
> my %parm;
>
> $apr = Apache::Request->new($r);
>
> if($r->method() eq 'POST' || $r->method() eq 'GET')
> {
> my @keys = $apr->param();
>
> foreach my $key (@keys)
> {
> $parm{$key} = $apr->param($key);
> }
> }
>
>
>
> So.. I can't really see how that would make us lose the parameters,
> especially since we doesn't lose them all the time, which was the case
> when I tried to get the same value twice...
>
>
> [Back to Wes]
> > If you are not already, then try
> >
> > $apr = HTTP::Request->instance($r); instead...
> >
>
> We use ->new now. Since we always only create one instance of it I
> thought there was no difference. Is instance known to be safer or so?
>
> Also got the hint that this could somehow be connected to caching, but
> since we when we output debug-messages see that handler() is called, with
> no parameters in $r, I don't see how this could be. Any comments, and
> suggestions of fix if this might be the problem?
>
> Thanks again,
> Hakan
>
> ([EMAIL PROTECTED])
>
> -
> Hi! I'm a .signature virus!
> Copy me into your .signature file to help me spread!
>
--
Nigel Hamilton
Turbo10 Metasearch Engine
email: [EMAIL PROTECTED]
tel:+44 (0) 207 987 5460
fax:+44 (0) 207 987 5468
http://turbo10.com Search Deeper. Browse Faster.
Re: [BUG] Losing GET/POST-data
On Wed, 2 Oct 2002, Wes Cravens wrote:
> On 02 Oct 2002 15:23 GMT I wrote:
>
> >
> > Hi!
> >
> > We're developing a perl module for apache/mod_perl, but have encountered a
> > really strange problem.
> >
> > After 'a while' we seem to lose the data sent to the apache-server, at
> > least it never reaches our module.
>
>
>
> > Recently we switched from using the standard Apache request-object to
> > using the Apache::Request one, for the added functionality, but this has
> > not had any effect at all as far as we can tell, and the bug keeps
> > happening...
>
> I ran into a problem that the param parts of a request were flushed
> when read for the first time... so if you lose them (don't store them)
> then you cannot access them again.
Yep, noticed this myself when re-writing it to check the input, should
have posted this first perhaps, but anyway, this is basically how we
handle the input:
sub handler($)
{
$^W = 1; # gripe about the little things
my $r = shift;
my %parm;
if ($r->method() eq 'POST') { %parm = $r->content(); }
elsif ($r->method() eq 'GET') { %parm = $r->args(); }
And now, after the re-write with Apache::Request
sub handler($)
{
$^W = 1; # gripe about the little things
my $r = shift;
my $apr;
my %parm;
$apr = Apache::Request->new($r);
if($r->method() eq 'POST' || $r->method() eq 'GET')
{
my @keys = $apr->param();
foreach my $key (@keys)
{
$parm{$key} = $apr->param($key);
}
}
So.. I can't really see how that would make us lose the parameters,
especially since we doesn't lose them all the time, which was the case
when I tried to get the same value twice...
[Back to Wes]
> If you are not already, then try
>
> $apr = HTTP::Request->instance($r); instead...
>
We use ->new now. Since we always only create one instance of it I
thought there was no difference. Is instance known to be safer or so?
Also got the hint that this could somehow be connected to caching, but
since we when we output debug-messages see that handler() is called, with
no parameters in $r, I don't see how this could be. Any comments, and
suggestions of fix if this might be the problem?
Thanks again,
Hakan
([EMAIL PROTECTED])
-
Hi! I'm a .signature virus!
Copy me into your .signature file to help me spread!
Re: Easy internal redirect question
[EMAIL PROTECTED] wrote:
> I've got a bit of a better grasp on the problem nowI think it's an
> interaction with POST data...
>
> I have a form in foo.html
>
>
>
> ...other form fields...
>
>
> I submit this form, and in /rms/admin, it gets handled like this
>
> # suck in form values, stick them in objects, blah blah, then get to the
> redirect...
> $r->internal_redirect('/rms/status?task=display');
>
> and what happens is that /rms/status complains that it doesn't know how to
> handle task=process_config. So, somehow the value for 'task' that was
> POSTed in the first request from the form gets passed onto the second
> request, apparently overriding the
> 'task' value of 'display' which I am trying to set in the url string I'm
> giving to internal_redirect().
you can only read POST data once, so once it's slurped from the main
request it's gone unless you store it someplace. for it to show up in
the internal redirect (outside of your object) you'd have to follow
the example of changing a POST to a GET and stuffing the POST data in
the query string (using something similar to recipe 3.18 and/or the
example in the Guide).
so, it sounds like your object is bleeding data over from the main
request into the redirect.
>
> I don't want any of the POST data to get passed onto that redirect.
it shouldn't be there. try reading from $r->content and $r->args in
the redirect and see what you find.
> Any
> thoughts? I saw a note in the API docs that $r->args() can be used to set
> the query string and that this is useful when redirecting POST requests. I
> tried doing a $r->args('task=display') right before the call to
> internal_redirect, but no luck.
setting $r->args in the main request won't bleed over either. I went
through the code for ap_internal_redirect yesterday and it definitely
takes the query string from the passed in URI.
HTH
--Geoff
install/config mod_perl-2(1.99_08)
Is there something in the configuration not jiving? Windows 2000, Apache 2.0.42, mod_perl-2(1.99_08-dev via ppm) In http.conf I have:Include conf/test.confAddHandler cgi-script .cgiIn test.conf I have:PerlRequire "C:/Apache2/conf/startup.pl" Options +ExecCGI SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders#ScriptAlias /test/ "C:/Apache2/htdocs/test/" startup.pl looks like:#!C:/Perl/bin/Perl.exeuse Apache2();use ModPerl::Registry ();1; Apache starts up. I can see mod_perl loaded in via server-status. And when I call just the directory /test/, this what I get in the error log: [error] 1932: ModPerl::Registry: C:/Apache2/htdocs/test/ not found or unable to stat If I try to call index.cgi under /test/index.cgi, the page just hangs. index.cgi works as a straight CGI page. Here it is:#!C:/Perl/bin/Perl.exe print "Content-type: text/plain\n\n"; print "mod_perl 2.0 rocks!\n"; --- I'll keep trying. Hopefully, there's an easy solution to this. Thanks.Do you Yahoo!? New DSL Internet Access from SBC & Yahoo!
Re: Defaulting to default-handler from custom handler
>
> All four cases result in the Perl code being displayed instead of the
> script being executed? If a location is defined as a ScriptAlias, then
> is the default-handler == perl-script? and would returning DECLINED
> result in mod_cgi handling the request? What am I doing wrong?
perl-script is mod_perl
default-handler is the Apache default (to just send the document)
cgi-script is mod_cgi
so, if you want mod_cgi to do it, try
$r->handler('cgi-script');
return DECLINED;
but I couldn't get that to work from a Registry script, since I
suspect that it's too late to alter the course of the request via
$r->handler(). a PerlFixupHandler is generally a good place to alter
$r->handler() to perhaps you can put your logic there instead.
we talk about $r->handler() a bit in chapter 14 in the Cookbook, and
14.1 has a list of modules and their corresponding handler name.
HTH
--Geoff
Re: cookies and IE
> Wouldn't be the first time I've been wrong. I do know that I was > seeing inconsistent behavior with cookies not being saved in a > redirect page (mostly IE PC, but not 100% of the time), but I didn't > spend any time worrying about it because of the previous messages I > remembered. A quick check of my mailbox shows a discussion back in > March where someone suggested using Refresh instead of Redirect to > get around the problem. I recall previous discussions, but I don't > have any on file. Actually, I had the same problem with certain versions of IE not setting cookies when they are used with redirects... I ended up making it so that the redirect was unnecessary. After a while I switched to HTTP authentication - In many ways it's even simpler :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: urls with session info
On Thu, 3 Oct 2002 00:43:12 -0500 (CDT) Gabriel C Millerd <[EMAIL PROTECTED]> wrote: > i have been trying to write a handler that will provide me with session > data using the URL (eg, http://www.domain.com/$sessionid . $r->url) like > the eagle books has on p246. >in addition i am serving a cookie with that same $sessionid and then > comparing to two $sessionid's in order to prevent the leaking referrer > information and other problems. >i am using apache::session::flex for my session information. >i am running into a lot of operational problems and i think i am > looking at restarting this little project of mine. >i want to do this for caching of expensive personalized webpages for > people would be great if i could. > >is there a a:session package already out there that does this? there > sure are a lot of them. seems that there are none that manipulate the url > however in the perltranshandler however. > >thanks Hi Gabriel, I've written a mod_perl module that does what you want. Apache::SessionManager - an Apache mod_perl module to manage HTTP sessions. Apache::SessionManager is a mod_perl module that helps session management of a web application. This simple module is a wrapper around Apache::Session persistence framework for session data. It creates a session object and makes it available to all other handlers transparenlty by putting it in pnotes. You can download it from CPAN: http://www.cpan.org/modules/by-authors/id/E/EN/ENRYS/Apache-SessionManager-0.02.tar.gz See perldoc Apache::SessionManager for more details. The current version is 0.02 but I will put 0.03 today to CPAN (there's support to all cookies attributes customization and a support to mod_backhand cookie-based load balancing). - Enrico
