cgi_to_mod_perl manpage suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I just got around to playing with mod_perl after a considerable amount of time that I'd relied on mod_Cgi. First and foremost, I really, really, really love it and would have switched much sooner had someone simply explained to me the one difference that I was unaware of until I decided to bother looking (and I think many people suffer from this): that while mod_cgi calls a wrapper to run a script, mod_perl does it internally. Once I understood that, I read up and installed it as soon as I felt I had some idea what I was doing. The move was uneventful (I just built it as a DSO and changed my ScriptAlias to a normal Alias, and added PerlHandler, SetHandler, etc). The only problem was the PerlSendHeaders option. The first fifty or so times that I read the manpages, I understood that PerlSendHeader On means that mod_perl will SEND HEADERS, and that off meant supply your own... Somehow I figured out (eventually) that this was not so, switched all of my deliberately placed PerlSendHeader Off statesments to a single On statement, and all of my scripts once again work. I think the main problem was the line : By default, mod_perl does not send any headers by itself, however, you may wish to change this: PerlSendHeader On That seems to say that if you want mod_perl to handle headers for you, cange it to On. Perhaps I'm still newbie enough that I still am missing the idea, but if I am correct, it would probably be a good idea to change (or even remove) that line from the man-page. Issac Goldstand - Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOq4VX4yEdnXg+lYbEQI8ngCgxZbrEAF1JpMuQ/SWV3jdMJp7EY8An38D kJn5xEGiYaV0ZBW27oBB3Vpk =rmm0 -END PGP SIGNATURE-
Re: cgi_to_mod_perl manpage suggestion
- Original Message - From: "Perrin Harkins" [EMAIL PROTECTED] To: "Andrew Ho" [EMAIL PROTECTED] Cc: "Issac Goldstand" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 4:56 AM Subject: Re: cgi_to_mod_perl manpage suggestion On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. I certainly want newbies to understand the docs, but the man page does say very explicitly "Just as with mod_cgi, PerlSendHeader will not send the MIME type and a terminating double newline. Your script must send that itself..." Those were the lines that finally caused me to even try it the other way. But although they are there, they took me a long time to comprehend after the previous (and even possibly subsequent) misunderstandings. Issac
Re: cgi_to_mod_perl manpage suggestion
- Original Message - From: "Bill Moseley" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 4:34 PM Subject: Re: cgi_to_mod_perl manpage suggestion At 03:34 PM 03/14/01 +0200, Issac Goldstand wrote: On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Read it again. You are confusing "some" headers with "all" headers -- there's more than just Content-Type:. To me it doesn't sound at all like it will send content-type: PerlSendHeader On Now the response line and common headers will be sent as they are by mod_cgi. (response line and common headers != content type) And, just as with mod_cgi, PerlSendHeader will not send a terminating newline, your script must send that itself, e.g.: - print "Content-type: text/html\n\n"; All documentation has room for improvement, of course. It's confusing if you haven't written a mod_perl content handler before (or haven't read the perldoc Apache or the Eagle book) and don't know that you need $r-send_http_header under a normal content handler. And if you are like me, you have to read the docs a few times before it all makes sense. Also, note that Apache::Registry lets reasonably well written CGI scripts to run under both mod_cgi and Apache::Registry, which is what that man page is describing. It's not a CGI script if there's not a content-type: header sent. And the docs are not implying that you can turn on PerlSendHeader and then go through all your CGI scripts and remove the print "Content-type: text/html\n\n" lines. Bill Moseley mailto:[EMAIL PROTECTED] So basically, PerlSendHeaders On means that it will send information such as the return code (eg HTTP/1.1 200 OK) ETag, Date and other headers that Apache generally handles on its own under mod_cgi? If so, then I think that all that really needs to be done is instead of giving a small lecture on PerlSendHeader which will be confusing to newbies, why not just write something basically telling them to set it to On and not worry. Remember that this is just the porting manpage, and if people really want to make their own handlers then they'll eventually learn the ins and outs of PerlSendHeader.
Varaible scope memory under mod_perl
I have a module that I built on my own to handle
user authentication. At the moment, every perl script that I have calls a
method in this module using a cookie (Supplied by browser) as an argument.
Eventually I want to turn this into a mod_perl handler which instead of
returning the autherized user information (in a scalar called $uid) will add a
key to $ENV containing the authorized user id.
However, for the moment I have trouble in that the
$uid variables (or possibly the $cookie variables) are being remembered between
callings of the scripts. This results in unauthenticated users recieving
access t incorrect accounts. (Even authenticated users get other peoples
accounts occasionally).
In short, the module is called TFile::Authenticate,
and it has a "use" line in my mod_perl startup script, to maximize persistance
and minimize compile/load time. Additionally, each cgi script (for they
are still all scripts) "use"s the module.
Basically, the common authorization code in each
script looks something like this:
my $q=new CGI;my
$cookid=$q-cookie('sessionlid');if (!(defined($cookid))) {print
"Location: /login.html\r\n\r\n";exit;}my $uid=eval 'check_auth($cookid);';
#The above line calls the authentication script
which will return a valid $uid or undef if not validif (!(defined($uid)))
{print "Location: /login.html\r\n\r\n";exit;}my
$cookie=$q-cookie(-name="sessionlid",-value=$cookid,-expires=expdate_auth($cookid));
The scripts then proceed to do their work and when
they return content, contain the command
print STDOUT "Set-Cookie:
$cookie\r\n";
Now I _know_ that some of the variables are being
persistant, because when doing a telnet localhost 80, and requestinga
script,I actually got a responseincluding a cookie for a valid
authentication. Now, I'm still really not sure about
howthepersistance works, so I suppose I could just do something
like:
my $uid=undef;
my $cookid=undef;
my $cookie=undef;
...
If I include that at the beginning of all of the scripts, it could work,
but it seems to me to be a bit messy; I'm sure there's a better way.
Additionally, can anyone think of a better way toadd a handler to the
existing TFile::Authenticate module for mod_perl scripts, while leaving the
public interfaces open fornormal CGI (or any other) scripts?
Thanks,
Issac
Internet is a wonderful mechanism for making a fool
ofyourself in front of a very large audience.
--AnonymousMoving the mouse won't get you into trouble...
Clicking it might. --AnonymousPGP Key 0xE0FA561B -
Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA
561B
Re: cgi_to_mod_perl manpage suggestion
Possibly. I think the idea is to keep in mind that people who are reading cgi_to_mod_perl are total newbies. Not only that, but many are planning on staying total newbies forever; they don't care about what mod_perl is actually for (or actually can do). I think that the cgi_to_mod_perl manpage should be targeted at that kind of perspective... Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "Perrin Harkins" [EMAIL PROTECTED] To: "Issac Goldstand" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 9:30 PM Subject: Re: cgi_to_mod_perl manpage suggestion On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? - Perrin
The right way to do authentication with mod_perl
I've been self-debating a small issue for a small project that I'm developing, and thought I'd pass it on to see if I can get any feedback from the experts in the field: I have a pair of login/logout CGI scripts on a machine that I recently "bumped" from mod_cgi to mod_perl. They set/removed a cookie that as a key in Jeffery Baker's wonderful Apache::Session module, which I used as a base for my own authentication module (and if Jeffery is reading this,I'd love your feedback about it...). Now, since I am using mod_perl, I've set up my module to be pre-loaded to keep a persistant connection to my session database (the connections to the authentication [via user/password] database is only done in the login script). It seems to me that I _ought_ to try to squeeze a bit more out of mod_perl by assigning a handler during some stage of the server request to do the cookie authentication and then, instead of my scripts checking with the authentication module, I can set an %ENV variable with the authentication results, for later parsing by the scripts. So, firstly, where is the best place to put the handler? Logic would suggest the _authentication_ stage, of course, but I'm still a tiny bit too newbie too know exactly how I'd have to set up the .htaccess .htpasswd files, let alone what kind of response I have to send back to the server. (Links to the mod_perl Guide are fine for answering this. I have, truth to tell, not quite finished reading the whole thing, but I have people pressuring me to fix the login buisness which, as a result of moving to mod_perl, is now quite a mess so I'm doing the unthinkable and asking even though I have not read every bit of documentation :-}) Secondly, there are one or two scripts that have a "guest" login. The way this works, in short, is that authentication is pre-generated and coupled with other "challenge tokens", which are all passed as part of the URI. This would obviously have to bypass the "normal" login/authentication handlers. The solution which leaps to my head is doable, if a bit crude: make a special aliased directory for guest-login-related scripts (actually only the original authentication [eg, first request] has to be via URI; I can switch to normal cookie based beyond that). But I'd really like to hear what people who've been developing mod_perl 'application's for more then just a few weeks would say. Thanks, Issac BTW: For the experts here, I must say that I'm really impressed with the mod_perl mailing list in general. I find that I'm learning almost as much from here as I do from the guide and manpages, and I am most impressed at the general attitude towards newbies. I've been a newbie, and a regular, on many technical mailing lists, but almost never seen that John Q. Newbie got decent attention on most of them. I just felt that gratitude ought to be expressed where it is due. Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --AnonymousMoving the mouse won't get you into trouble... Clicking it might. --AnonymousPGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: [OT] ApacheCon BOF
Randal 42 billion has the right sound to it. It's "the answer", after all, Randal a billion times over. :) I like it! Maybe a big round pearl with a smiley-face and a headband with feather sticking up in the back with the words "Don't Panic" in large friendly letters printed below :) Take it one step further... How about a nice camel with a nice feather-ed headband, a big tatoo of the number 42 (maybe another feather there too?). Above it written mod_perl, and below in nice friendly letters: Don't Panic. Issac
Apache::Cookie-bake - When?
I'm slowly porting my development scripts from mod_cgi to mod_perl. I just moved my main authentication handler to PerlFixupHandler (later I'll probably move it to AuthenHandler, but I just want it to work for now). In any case, all of the sudden, my upload script is choking and giving me 400 (Bad request) errors. I wanted to ask if this is because I'm new() and bake()ing a session cookie before I even get around to parsing the upload (and any other data, for that matter), or am I barking up the wrong tree? The upload script itself was working very nicely under Apache::Registry and is using CGI, not Apache (yet). Any ideas? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --AnonymousMoving the mouse won't get you into trouble... Clicking it might. --AnonymousPGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: modperl security model question
Hmm... There might be another solution, but it's probably a bit dangerous - and in any case, one of the more experianced mod_perl people would have to confirm that it works as expected... But it would seem to me that if you can figure out at an early enough stage who you want to run the process as, you could set Apache to run as root:root and then use a ChildInitHandler (or any early stage handler) to do a setuid and setgid. Since perl is part of the child process, this should change the uid gid of the entire process. This would seem slightly better then the below alternative as you can set MaxRequestsPerChild to 1 and just have one parent process spawning children with different uid/gids, instead of having to start up an entire server for each uid/gid pair... Of course, there's the security problem of everything that happens in the child until it gets to the setuid AND it's very important to make sure that there's a default uid/gid pair for the process to put on to prevent any sort of bypass. I don't know that I'd pick this solution without mulling it over for a few days, but maybe people on the list can think up some of the pro's and con's for me :) Issac (PS. Yes I know it's a dangerous approach, so you don't all have to personally bash me over the head with it ;-) ) Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "sterling" [EMAIL PROTECTED] To: "Thomas K. Burkholder" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, April 15, 2001 6:06 PM Subject: Re: modperl security model question On Sun, 15 Apr 2001, Thomas K. Burkholder wrote: Thanks again for the help - I have another one- My application consists of perl modules with file permissions set only to a particular user 'burkhold'. The database password is kept in plaintext in one of those modules. I use the User: and Group: directives in access.conf to cause the uid of the spawned httpd process to have permission to execute the code. It works fine, except that it seems I can't embed 'User: burkhold' inside a Location directive, so all requests have to be served as 'burkhold'. It seems like there should be some simple way in apache to specify what user the httpd should be set to when it's spawned, but except for the global User: I haven't found a way. An httpd process is spawned to handle _all_ locations, that is why the Group/User can only be specified per server. If apache was able to spawn separate processes to only handle one location, your suggestion would work. The only solution i would offer would be to proxy all requests to that location to another apache server, running on a different port, as user bukhold. The main server could then run with whatever user is appropriate, and have a ProxyPass directive to forward requests requiring user burkhold. sterling If I can't make this work, I may have to turf module handlers and go with a Registry and setuid solution, which I think would be a shame since I think handlers are a lot more elegant. This is probably well-trodden territory - anyone got a solution? Thanks again, several of you have been helpful to me, and I do appreciate it. Happy Easter. file://Thomas Thomas K. Burkholder [EMAIL PROTECTED]
Re: modperl security model question
darren chamberlain wrote:
Be sure to check that $line is defined:
Even better:
perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
my $line = $input-getline() || 'some safe default value, like
""';
die "\$line is not defined" unless (defined $line); # -- Now not really needed
print STDERR $line;
$input-close();
# $line = 'bar';
$Location{'/areaj'} = {
PerlSetVar = [
[foo = $line]
],
SetHandler = 'perl-script',
PerlHandler = 'AreaJ::AreaJ'
}
#push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
/perl
Issac
--
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Must restart Apache when any .pm changes?
man Apache::StatINC Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "Steve Leibel" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 22, 2001 4:14 AM Subject: Must restart Apache when any .pm changes? I'm experimenting with using Perl modules (.pm files) underneath Mason components. As far as I can see, the only way to guarantee that changes made in the .pm are seen by the Mason code is to restart Apache whever the .pm file changes. This is true whether the "use" statement is in handler.pl or in the component. I believe the way this works is that the first time any Apache child process sees "use Foo" that is the version of Foo.pm that will be used by that process. No subsequent "use Foo" within components will have any effect during the life of that Apache process. Am I understanding this correctly?
[OT] mod_perl 2 question...
I was just looking at Doug's overview of mod_perl 2, and was specifically intrigued by the PerlInterpLifetime directive, which got me sorta excited. It would appear to me, based on that, that by setting PerlInterpretLifetime connection, you could have a good chance at getting good persistant "session"s with any HTTP/1.1 client, with no more than plain ol' global variables. Moreso, you can see which is the first request easily just by checking defined($someglobalvariable) - or so it would appear... Can any of the mod_perl 2 people provide some feedbak on this, as I'm sure you guys have looked at this much deeper than I have. Thanks, Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --AnonymousMoving the mouse won't get you into trouble... Clicking it might. --AnonymousPGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: cookies work for some browsers, not for others... ?
- Original Message - From: will trillich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 9:44 PM Subject: cookies work for some browsers, not for others... ? [snip] cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? That's the formatting done for the chunked content-type. I really don't recall exactly how it works. All I remember is that each set of hexadecimal digits [that's what they are] somehow must represent the next chunk to be transferred - it might be a byte count. In any case, if you're REALLY interested, go look it up in the RFC for HTTP/1.1 - it's explained in better detail there. [snip] HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? See above. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: cookies work for some browsers, not for others... ?
- Original Message - From: will trillich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 9:44 PM Subject: cookies work for some browsers, not for others... ? [snip] cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? That's the formatting done for the chunked content-type. I really don't recall exactly how it works. All I remember is that each set of hexadecimal digits [that's what they are] somehow must represent the next chunk to be transferred - it might be a byte count. In any case, if you're REALLY interested, go look it up in the RFC for HTTP/1.1 - it's explained in better detail there. [snip] HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? See above. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: forbidden vs. cookie
I did this in a module of mine. I simply did a new Apache::Cookie and
$cookie-bake() followed by
$r-header_out(Location=http://go.here/now;);
return HTTP_MOVED_TEMPORARILY;
I chose TEMP_REDIRECT as I think it's befitting as the above is (also) from
an AuthenHandler and therefore constitute a problem that's not based on the
content of that specific URI...
Anyway, hope this helps.
Issac
- Original Message -
From: will trillich [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 9:31 PM
Subject: forbidden vs. cookie
i could really use some dumbed-down tips on setting cookies
during a redirect. boy, this is really getting to me.
using apache 1.3.9 on debian 2.2/potato
in trying to implement the concept of the Apache::Ticket*.pm
modules from the Apache Modules (eagle) book in chapter 6
(on pages 304+) i'm running into browser compatibility problems.
SOME browsers (differs among platforms, too) see the forbidden or
redirect codes and take action immediately, ignoring any
set-cookie headers that are also sent.
as a workaround, i was trying to change TicketAccess.pm to
# the munged version trying to accomodate rude browsers:
package Apache::TicketAccess;
use strict;
use Apache::Constants qw(OK FORBIDDEN REDIRECT);
use Apache::TicketTool ();
sub handler {
my $r = shift;
my $ticketTool = Apache::TicketTool-new($r);
my($result, $msg) = $ticketTool-verify_ticket($r);
unless ($result) {
$r-log_reason($msg, $r-filename);
my $cookie = $ticketTool-make_return_address($r);
#the original code that works for SOME browsers:
# $r-err_headers_out-add('Set-Cookie' = $cookie);
# return FORBIDDEN;
my $login_uri = $r-dir_config(TicketLogin);
# as AccessHandler, this was very much a bad idea:
# use CGI '-autoload';
# print
# header(-refresh = 1; URL=$login_uri, -cookie = $cookie),
# start_html(-title = 'Redirecting to login', -bgcolor = 'white'),
# h1('Gotta log in, first'),
# p(You're being redirected to ,
# a({-href=$login_uri},$login_uri),
# in just a moment.),
# h2(Please stand by...),
# end_html();
# return OK;
# it does manage to redirect the browser but there's lots
# of duplicated headers and garbage (plus just hitting the
# BACK button bypassed the need to log in)
# this don't work so not, neither:
$r-header_out(-cookie=$cookie);
$r-header_out(-location=$login_uri);
return REDIRECT;
# neither header is sent.
}
return OK;
}
1;
__END__
i've spent hours flipping back and from from the index to the
text, slapping postit notes on every other page, scanning
Apache::*.pm source code -- and it's still not sinking in... a
little help would be appreciated!
AAUGH!
--
[EMAIL PROTECTED]
Where exactly is the Perl interpreter?
I was just wondering- where exactly is the Perl interpreter in mod_perl 1.25 (for Apache 1.3) and where will it be in mod_perl 2 (Apache 2.0)? I assume in Apache 1.3 it's in shared memory, but I want to double check... Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Apache::DBI missing methods?!
Hi, I've just joined the list looking for an answer to this. A couple of others have posted the same problem but I couldn't find any answers. I'm running RH6.2 with standard Apache, perl and mod_perl rpms. I'm hitting a brick wall if I include a 'PerlModule Apache::DBI' line in httpd.conf - Apache starts up but shuts down immediately. I created a test script that just use's the module and I get the following error Can't locate object method module via package Apache at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 202. BEGIN failed--compilation aborted at ./test.pl line 4. Which must be what's frying httpd. Well, first of all, you can't just make a perl script with use Apache::xx and expect perl to run it - the Apache::xx family is only usable from within the mod_perl environment, so that's probably what's causing your error - but that wouldn't happen in Apache... Try looking at your error_log for clues on what's killing Apache. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: [DIGEST] mod_perl digest 05/13/01
-- mod_perl digest May 13, 2001 - May 19, 2001 -- Recent happenings in the mod_perl world... mod_perl status o mod_perl - stable: 1.25 (released January 29, 2001) [1] - development: 1.25_01-dev [2] o Apache - stable: 1.3.19 (released February 28, 2001) [3] Nope - stable is 1.3.20 (fixing a Win32 issue) released May 15, 2001 - development: 1.3.21-dev [4] o Perl - stable: 5.6.1 (released April 9, 2001) [5] - development: 5.7.1 [6] Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Apache::Session / No-Cookie-Tracking
Is it a secure website? If so, it could be using the SSL unique ID which, if I'm not mistaken, is persistant through the SSL session (so the server doesn't have to redo the handshake on each connect). Issac - Original Message - From: Jonathan Hilgeman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 25, 2001 6:29 PM Subject: FW: Apache::Session / No-Cookie-Tracking Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/) | | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Handling the 'User pressed Stop button' case - not working
Just wanted to comment that that idea won't work on uploads (where the delay is caused by information in the _request_ taking a long time to process [read send]). But I seem to remember hearing someone who was making a patch to add an upload hook for apache - do I remember correctly? Issac - Original Message - From: John Hurst [EMAIL PROTECTED] To: Matthew Darwin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, May 26, 2001 12:00 AM Subject: Re: Handling the 'User pressed Stop button' case - not working Matthew Darwin wrote: On Sat, 26 May 2001, Stas Bekman wrote: You right. It seems that mod_proxy won't abort on SIGPIPE. So how can I get it to without breaking everything else? Any ideas? I have a process that takes 2-3 minutes to run before the user gets any any output. I tell them to wait, but they get impatient. If they hit STOP I really want to know about it so I can free up CPU resources for when they hit RELOAD to try agin. Any helpful hints would be most appreciated. Run the process in the background. Have the browser loop on a reporting URL w/request ID. That will allow you to show progress: * The initial request generates a processing job. Please see previous threads regarding the wisdom of forking mod_perl processes. You may want to consider writing a lightweight daemon to take processing requests from mod_perl via a unix domain socket. * Return a starting page to the client which will refresh to a progress reporting URL, which may be the same URL as the original request (be sure to include a UUID or some other identifier for the job). * Each time the progress URL is called, check on the status of the processing job. Return the data if available, or return another refresh. Also: * The progress URL can use the UUID to generate updated status info. If you are clever, you can even offer a status bar. * If you keep the results of your processing jobs indexed by, say, the MD5 of the request parameters that created them, you can skip redundant processing runs. -jh
Re: User tracking in IE 6
I've already started toying with IE6 (to look at the XML handling, actually - which is pretty decent so far). But what IE 6 does is it somehow checks privacy statements (no idea how it looks at 'em, though). If there's a problem it shows you a tiny icon near the security icon. If it's really bad, it's red - minor problems are yellow. In any case, by default everything's enabled, I think, but there's options to start disabling problematic third-party sites. Issac - Original Message - From: Differentiated Software Solutions Pvt. Ltd., To: [EMAIL PROTECTED] Sent: Saturday, May 26, 2001 1:40 PM Subject: User tracking in IE 6 Hi, This is related to other thread on user tracking I've been reading up a bit on the upcoming IE6 release. Couple of facts which may bite some of our software are a) By default 3rd party cookies are to be disabled in IE6 b) Implementation of P3P in IE 6. Our software is a 3rd party adserver which uses cookies. (We are not using it for privacy but find it more convenient to track clickthroughs). We are planning to have a minor release of our software in the post IE6 era. We wanted thots on -- How are other people going to handle cookies with IE 6. Have any of you tested it ? -- Links / material which will help us understand P3P in the context of cookies. Most links we found are talking about the full-policy of disclosing privacy info. We wanted more info on the compact policy of handling cookies. Thanks, Murali Differentiated Software Solutions Pvt. Ltd.,90, 3rd Cross,2nd Main, Ganga Nagar,Bangalore - 560 032Phone : 91 80 3631445, 3431470Visit us at www.diffsoft.com
Re: Real Widgets and Template Languages
My $0.02 on XML config files. Although they may be attractive to some, personally, I don't like them. I see XML is merely the expression of the configurable parameters of the object. IE it is just a means to the end. Personally, I would like to define my widget properties through a GUI and then will probably use Storable to dehydrate and rehydrate my widget objects. I would never want to code up XML data and I don't think I'm alone. :) Definately when it comes to interchanging your widget data with another system something like XML really starts to make sense. I don't think it makes sense necessarily for your internal day-to-day operations. What I would advocate is that there are a variety of sources for widget configuration data from something as simple and elegant as Perl code to XML of some layout to Storable data stored in a blob field of a DBI source. Actually, I personally think that you're both correct here - I think the proper way to stash the widgets would be through Storable. If you wish to do it through XML, then that should call for an extension to Storable which can store/retrieve data from XML. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Content-Disposition to change type and action?
Hi there, On Tue, 29 May 2001, Jay Jacobs wrote: I've tried setting $r-content_type and even $r-filename to try and get the browser (ie 5 for now) to see it as a non-html file and do the right thing. IE is particularly fond of ignoring Content-type. If the file is called something.html or something.htm I've found IE will treat it as html even if you say it's text/plain in Content-type. Ugh. no - that only happens when you supply text/* (and possibly image/*). I've had reasons to force internet explorer to do what I want (down, boy! :-) ) and after a bit of hassle, I usually can just by setting the content-type in a way it likes (which is uslally compatible with the other browsers, too). Issac
Re: Real Widgets and Template Languages
Wait a second, here... I was under the assumption that the Widget library was not going to be limited to HTML output only. According to your page, it seems that the only customization that you plan on doing is to modify the HTML to work properly with specific browsers (eg, MSIE vs Mozilla/Netscape). I think it's an important idea to leave the Widget totally language independant - so thast in addition to HTML, you could render these widgets on cell phones (WML) or Palm Pilots or whatever... Hell, you _should_ theoretically be able to render these using Win32 API if someone decided to write code to export to C/C++ or VB - or Ximian/GNOME - or whatever! Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
[OT] mod_mime_magic in perl?
Does anyone know if there is a perl module that implements the features of Apache's mod_mime_magic module? (e.g., you give it a file handle, or data and it tries to autodetect the correct mime-type) Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Help with parameters.]
Original Message
Subject: Help with parameters.
Date: Tue, 29 May 2001 11:12:46 -0500
From: Nimmagadda Rajeev SRK [EMAIL PROTECTED]
Organization: IBM Corporation.
To: [EMAIL PROTECTED]
Hi,
I have built modperl 1.25.
I could run perl scripts fine.
How can I send parameters to a perl scripts?
Using http://mydomain.com/perl/foreach.pl?200+300 does not seem to work.
you'll need to do it as something like
http://mydomain.com/perl/foreach.pl?num1=200num2=300
then do :
my $q=new CGI;
my $num1=$q-param('num1');
my $num2=$q-param('num2');
Parameters work a bit different in mod_perl.
Issac
PS. Stas - you DID remember to put this into the book somewhere... didn't
you? I'm sincerely praying that I just don't remember where... :)
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: [OT] mod_mime_magic in perl?
On Wed, May 30, 2001 at 05:21:22PM +0200, Issac Goldstand wrote: Does anyone know if there is a perl module that implements the features of Apache's mod_mime_magic module? (e.g., you give it a file handle, or data and it tries to autodetect the correct mime-type) Here's a module (File::Type) that I've been meaning to clean up for CPAN for a while. It's in alpha, but it works for me so far. http://slaysys.com/src/Type.pm The magic it refers to must be a Perl data structure, not a real magic file, though I'd really like to get to parsing real magic files. If you want to use it, let me know and I'll CPAN it sooner. It will need some MIME types added or a parser for a real MIME types file. Well, it looks great except that most of the types are just different flavors of text/plain... If you do implement real magic files (look at the files the Apache uses for good example magic files), or even get a bigger list in your module, PLEASE let me know. Aside from that lack, it's perfect for me. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Real Widgets and Template Languages
At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote: At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote: At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote: ... $widget = $wc-widget(first_name); print First Name: , $widget-html(), \n; A widget type has already been defined. So I don't see that the method to output it's display should be called html() which is, well, HTML specific. I prefer print First Name: , $widget-display(), \n; Since widgets are components that know how to display themselves whether its WML or HTML or whatever. This is a philosophical design decision that I have been struggling with. The widget does indeed know that it should generate HTML, so it could have a method, $widget-display(), $widget-draw(), etc. However, this implies that the widget has the freedom to decide how it should render itself and that the caller does not need to know. This is not correct. I think it is correct. The widgets are specific to the technology like HTML or WML or whatever. It's up to your config in the Controller to determine which widgets you are putting into the controller. If you want to display both WML and HTML, you would create a WML controller and an HTML controller. Note that the controller itself doesn't know the difference, but you just are using it as a collection mechanism to group together like-sets of widgets. This is true, but that's not a really good design plan. Now I still haven't quite understood how the different base classes work together, so I can't suggest a specific implementation strategy yet, but IMHO you should be able to create Widgets dynamically for any target UI, with widgets that are nativelly unsupported in a specific UI (eg, WML vs HTML) doing some default action (AUTOLOAD somewhere?). Now I agree with Gunter in that $MyWidget-DisplayHTML() vs $MyWidget-DisplayWML() is the wrong way of doing it. But I was sorta thinking along DBI's way of doing things in that you load a driver first - the driver being the UI link, and then $MyWidget-Display() would automatically use the correct driver for outputting stuff. Before I go any further, I should mention that I still haven't understood all of the terms that Stephen uses when describing the Widgets, so if I'm repeating something here that anyone already said, please let me know what part of the existing interface I'm describing... Now, the only problem is how to make the default actions (for Widgets that are unsupported by the driver). I need to think about this a bit more, but it'll probably take an AUTOLOAD per-widget and/or a specific function (not AUTOLOAD) per-driver... The caller in this case has already cooked up a bunch of HTML and is counting on the widget to produce HTML which can be inserted. The widget does *not* have the freedom to render any other way. This is why I have (sort of stubbornly) stuck with the $widget-html() method despite the unanimous suggestions for a $widget-display() method. and then also -wml() and -X() and whatever else? This does not seem right. I do believe there is a place for a display() method, but it is at the controller level. The is the level at which the caller may not know what technologies are being used by the widgets. Yes its not at the controller level. It is at the widget level. So you have Widget::WML::TextField and Widget::HTML::TextField... And the firsto ne would go into a controller that is set up to contain WML widgets in general and the second would go into a controller that is set up to contain HTML widgets in general. This is also doable, but only if it's transparent to the user. In other words, the developer _using_ the widget would have to mkae a Widget::TextField, and only when it was _rendering_ the Widget, would the libraries internally read the information in Widget::HTML::TextField or Widget::WML::TextField - otherwise, it's just not worth making generic widgets. This whole discussion brings out two other important design decisions. 1. What are the UI technologies we really wish to support? (i.e. is this *really* a Widget or an HTML::Widget library?) 2. Which classes represent Logical Widgets and which Physical Widgets? 1. TECHNOLOGIES I propose that the following technologies will have supporting Controller/State/Widget combinations to make this not just another web widget library. * CGI/HTML - a web application * mod_perl/HTML - similar, a web application using mod_perl * WAP/WML - driven from a WAP device * X11 (Gtk-Perl)- an X windows application * Curses (terminal) - a screen-oriented terminal application * Term - a line-oriented (scrolling) terminal application * Cmd - similar to Term, but the state must be saved between each cmd (I know I'm stretching the paradigm a little bit here, probably beyond what is reasonable. If you don't think one or more of these is
Re: Real Widgets and Template Languages
At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
...
[...]
Complex Widget:
Widget type=textbox maxsize=50 length=25 X-Offset=40
Y-Offset=20
TabStop=True TabIndex=3 name=text1 value=some sample text
tooltip=Enter some text here/
Now, let's say that the developer prints this with the HTML Driver -
this
could do something like:
INPUT TYPE=TEXT MAXLENGTH=50 SIZE=25 NAME=text1 VALUE=some
sample
text onMouseOver=Window.status='Enter some text here'
onMouseOut=Window.status=''/
And in some other GTK-based environment, it could do something like:
Label text1;
with (text1)
{
.Length=50;
.Width=25*XCharSize; // The *XCharSize would have to be defined by
the
driver or by the native interface
.Height=1*YCharSize; // This would be a default setting plugged in
by
the driver
.Value=some sample text;
.Left=40;
.Top=20;
.TabStop=1;
.TabIndex=2; // 3-1 for 0 based - also defined by the driver...
}
Now, neither of these cases used _all_ of the widget parameters - a
simple
HTML designer could have produced an IDENTICAL widget by doing:
Widget type=textbox maxsize=50 length=25 name=text1 value=some
sample text tooltip=Enter some text here/
This shows a few things, actaully. First of all, the widget can get as
many
or few parameters as the developer wants to supply it with - extra
parameters will be discarded by drivers who do not understand them, and
missing parameters will be supplied with default values wherever
possible.
Now, I would suggest designing this such that the developer only
interacts
with a Widget::textbox. Internally, there would have to be a
Widget::HTML::textbox and a Widget::GTK::textbox, each with the
UI-specific
rendering instructions...
The only problem is making sure that the overhead is kept to a minimal -
in
that as few feautres that are not actually NEEDED for the specific
implementation are loaded as possible (eg, a user using only certain
elements in HTML will only load those elements, and only HTML, while if
he
wants WML, it will also incur WML generic overhead too). I think this
approach should satisfy both the wants to keep the widgets as generic as
possible, as well as Gunther's wanting to keep the widgets as simple and
easy-to-use/understand as possible (for beginners, at least).
While adding parameters to the constructor is not a problem, I guess I
have
a problem with adding behaviors. If you believe that simply adding more
config hooks to allow XWindows to be supported is doable, then we should
just leave it as mentioning this as a supposition and leave it to you or
someone else to prove that the supposition works after v1.x of the widget
set is released.
For arguments sake, I suppose it can be left as a supposition (OK, so I'm
too swamped just now to do a proof-of-concept [especially one that would
require me to learn GTK programming - something I've not yet touched]).
I still think that if a proper abstraction layer is implemented, then
parameters can either be guessed or silently discarded, thus enabling the
widgets to be rendered in anything - even XWindows (or Win32 using Vis
Basic, or a dialog resource file). Note that in these cases, only very
generic code can be generated, but it's still possible.
Re: Help with Cookie
Sometimes, that's a result of setting the path of the cookie incorrectly... see CGI::Cookie or Apache::Cookie for details on how to set them... Issac - Original Message - From: Bird Lei To: [EMAIL PROTECTED] Sent: Monday, June 04, 2001 09:54 Subject: Help with Cookie *Sometimes* my script cannot get the cookie info. I just wondering if this could be problems *other than* my script (eg ISP's caching, and so on).I am using CGI.pm to read cookie. The script that has problem is output the content of an image, that is, the users have to login to view the image. And another script, which also requires the same cookie info, generates the layout.That is, i have a script called photogallery.cgi that generates the follow output:output of photogallery.cgi ---htmlsomething here...the image goes here img scr="image.cgi?file_id=1234".../html---Then the script image.cgi will write to the browser the image content. Sometimes this script (image.cgi) cannot read the cookie info.I guess the problem should come from my code or the server setting.However, because I have investigated my script for quite a long time and cannot get a clue of what went wrong. So I want to check if others ever experienced this problem before.I am using Perl 5.6.0, mod_perl/1.24 Apache/1.3.14 IE 5.5.Bird
Re: Help with parameters.]
I have built modperl 1.25.
I could run perl scripts fine.
How can I send parameters to a perl scripts?
Using http://mydomain.com/perl/foreach.pl?200+300 does not seem to
work.
you'll need to do it as something like
http://mydomain.com/perl/foreach.pl?num1=200num2=300
then do :
my $q=new CGI;
my $num1=$q-param('num1');
my $num2=$q-param('num2');
Parameters work a bit different in mod_perl.
Issac
PS. Stas - you DID remember to put this into the book somewhere...
didn't
you? I'm sincerely praying that I just don't remember where... :)
What do you mean? Are you talking about $r-args?
http://perl.apache.org/guide/snippets.html#CGI_params_in_the_mod_perl_ish_
If so, yes, it handles empty values differently from CGI::param.
No. Since the book is designed for newbies, as far as I can see anyway, I
think that there should be a section somewhere explaining that parameters in
the CGI world work different from parameters in the command line script
world. You should explain how the argument array is not used in
CGI/mod_perl, but rather paramters are passed as key/value pairs which are
read from the request. Explain the basics of it, and maybe give an example
HTML snippet like:
INPUT TYPE=TEXT NAME=givenName
INPUT TYPE=TEXT NAME=lastName
INPUT TYPE=HIDDEN NAME=emailAddress VALUE=[EMAIL PROTECTED]
And explain that if the user typed in Issac in the first box and
Goldstand in the second box, his perl script would get these paramters in
a key/pair list (which can be placed into a nice little hash) and then
accessed...
Give a little example:
print Hello $form{givenName} $form{lastName}. Your email address is
$form{emailAddress}.\n;
That's what I was referring to. And I don't _think_ it's in the book. And
if you'll look at the original question, it apparatly IS a newbie issue.
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: switch user id
As far as I know, it does not exist now, but I believe it WILL be possible with Apache 2.0/mod_perl 2. Issac - Original Message - From: Miroslav Madzarevic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 09, 2001 19:02 Subject: switch user id As you know, apache runs as nobody.nogroup so these are the files I'm allowed to access. I wish to access files owned by otheruser.othergroup. How can I do this under mod_perl (mason) ? Is there a thing I can use to change my current uid so I can read the file or directory I don't own ? I don't want/cann't modify file permissions or ownership. Regards, Mire -- In a world without fences who needs Gates?
Re: detecting ssl
Not necessarily. I could easily set up any virtualhost on port 443 which
will be accessable by https://nasty.servername/ but will, in reality, not
necessarily be over a secure connection. $ENV{HTTPS}, on the other hand, is
set by mod_ssl, and is therefore a better sign to know that the connection
is really secure.
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: Geoffrey Young [EMAIL PROTECTED]
To: 'João Pedro Gonçalves' [EMAIL PROTECTED]; brian moseley
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 10, 2001 14:33
Subject: RE: detecting ssl
-Original Message-
From: João Pedro Gonçalves [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 9:08 AM
To: brian moseley
Cc: [EMAIL PROTECTED]
Subject: Re: detecting ssl
This approach should be ok:
my $s = $r-lookup_uri($r-uri);
my $ssl = $s-subprocess_env('HTTPS');
I looked at this a while back and this is usually set internally
in apache by the ssl implementation.
no need to do a lookup or rely on PerlSetupEnv On I wouldn't think...
my $ssl = Apache::URI-parse($r)-scheme =~ m/^https/;
?
--Geoff
Re: detecting ssl
-Original Message-
From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 10:44 AM
To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
Cc: [EMAIL PROTECTED]
Subject: Re: detecting ssl
Not necessarily. I could easily set up any virtualhost on
port 443 which
will be accessable by https://nasty.servername/ but will, in
reality, not
necessarily be over a secure connection.
what would negotiate the https protocol then? its not like you can just
set
up to listen on 443, make
a an http request, and Apache will serve it - at least not through a
browser
or telnet.
Of course it will!!! To prove it, I set up a relatively simple Apache
server with the following httpd.conf file. (I'm not sure how much I can cut
down the httpd.conf file, so there's probably still excess baggage here...)
-
ServerType standalone
ServerRoot /usr/local/httpd
PidFile /usr/local/httpd/logs/httpd.pid
ScoreBoardFile /usr/local/httpd/logs/httpd.scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 2
MaxSpareServers 6
StartServers 4
MaxClients 50
MaxRequestsPerChild 200
Port 443
Listen 443
User www
Group www
ServerAdmin [EMAIL PROTECTED]
ServerName some.domain.com
DocumentRoot /usr/local/httpd/htdocs
Directory /
Options FollowSymLinks
AllowOverride None
/Directory
Directory /usr/local/httpd/htdocs
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
/Directory
AccessFileName .htaccess
DefaultType text/plain
-
Then, I did telnet some.domain.com 443...
-
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2001 15:54:47 GMT
Server: Apache/1.3.20 (Unix) mod_perl/1.25 PHP/4.0.4pl1
Connection: close
Content-Type: text/html
-
Now, if I'd have checked the port, I'd be in trouble. Also, if I'd use a
simple client that just used https as port 443 without automatically trying
to use a secure layer (which is actually proper...), I could even grab
https:// from the URI request.
The ONLY safe way, is to use mod_ssl to tell you you're using it. Consider
a comparison: assuming you're using mod_perl by grepping the server info for
mod_perl/x.xx rather than checking $ENV{MOD_PERL}
Issac
Re: detecting ssl
-Original Message-
From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 10:44 AM
To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
Cc: [EMAIL PROTECTED]
Subject: Re: detecting ssl
Not necessarily. I could easily set up any virtualhost on
port 443 which
will be accessable by https://nasty.servername/ but will, in
reality, not
necessarily be over a secure connection.
what would negotiate the https protocol then? its not like
you can just
set
up to listen on 443, make
a an http request, and Apache will serve it - at least not through a
browser
or telnet.
Of course it will!!!
whoops, I meant an https request - of course you can listen on any port
you
want for plain http.
Then, you are correct. Of course you could simply just pipe the telnet
session through stunnel, or openssl, or whatever - and work something out
like that. But the point is, then it really IS an HTTP request going over
SSL, so mod_ssl will jump in and set $ENV{HTTPS} anyway, so that really
doesn't say anything.
[snip]
Also,
if I'd use a
simple client that just used https as port 443 without
automatically trying
to use a secure layer (which is actually proper...), I could even grab
https:// from the URI request.
ok, I'm not claiming to be an ssl expert, so how would one do that? if I
do
telnet my.ssl-enabled.server 443
GET / HTTP/1.0
I get 400 - BAD_REQUEST. something has to negotiate the https layer, no?
Of course. My point is that just because the server's listening on port
443, it doesn't necessarily mean it's using SSL. That's where the danger
is. By checking for $ENV{HTTPS}, you are eliminating that danger by
actually checking whether the individual requests are occuring over a secure
layer, rather than counting on the server and client to do what you would
expect them to - which is the worst mistake that we, as programmers, can
afford to make... :-)
I've been searching for documentation, but all I can find is the TLS spec,
which says that TLS is relegated to the scheme of 'https', so pointers to
something useful would probably be good (for all :)
Umm... If the RFCs aren't helpful, you can try fooling around with (and
reading the man page for) openssl's s_client mode...
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: detecting ssl
-Original Message-
From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 10:44 AM
To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
Cc: [EMAIL PROTECTED]
Subject: Re: detecting ssl
Not necessarily. I could easily set up any virtualhost on
port 443 which
will be accessable by https://nasty.servername/ but will, in
reality, not
necessarily be over a secure connection.
what would negotiate the https protocol then? its not like
you can just
set
up to listen on 443, make
a an http request, and Apache will serve it - at least not through a
browser
or telnet.
Of course it will!!!
whoops, I meant an https request - of course you can listen on any port
you
want for plain http.
Then, you are correct. Of course you could simply just pipe the telnet
session through stunnel, or openssl, or whatever - and work something out
like that. But the point is, then it really IS an HTTP request going over
SSL, so mod_ssl will jump in and set $ENV{HTTPS} anyway, so that really
doesn't say anything.
[snip]
Also,
if I'd use a
simple client that just used https as port 443 without
automatically trying
to use a secure layer (which is actually proper...), I could even grab
https:// from the URI request.
ok, I'm not claiming to be an ssl expert, so how would one do that? if I
do
telnet my.ssl-enabled.server 443
GET / HTTP/1.0
I get 400 - BAD_REQUEST. something has to negotiate the https layer, no?
Of course. My point is that just because the server's listening on port
443, it doesn't necessarily mean it's using SSL. That's where the danger
is. By checking for $ENV{HTTPS}, you are eliminating that danger by
actually checking whether the individual requests are occuring over a secure
layer, rather than counting on the server and client to do what you would
expect them to - which is the worst mistake that we, as programmers, can
afford to make... :-)
I've been searching for documentation, but all I can find is the TLS spec,
which says that TLS is relegated to the scheme of 'https', so pointers to
something useful would probably be good (for all :)
Umm... If the RFCs aren't helpful, you can try fooling around with (and
reading the man page for) openssl's s_client mode...
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: detecting ssl
On Thu, 12 Jul 2001, Issac Goldstand wrote:
IG == Issac Goldstand [EMAIL PROTECTED] writes:
IG Not necessarily. I could easily set up any virtualhost on port
IG 443 which will be accessable by https://nasty.servername/ but
IG will, in reality, not necessarily be over a secure connection.
I think you've never actually tried this. You will not get the page
because the client is expecting SSL and you're not providing it. Try
it. Go ahead, try it.
I did. Look at my follow-up to Geoffrey's esponse to the post you're
quoting for details... It worked from most simple clients...
your most simple clients example did the same as accessing
http://nasty.servername:443/.
That's about as different from https:// as if you had shown that
stuff on port 443 can be other stuff than HTTP over SSL by
installing an ftp server on that port.
Some clients, like Netscape and MSIE think that they're smarter
than the servers, though, and incorrectly assume they know
whether to go secure or not.
They don't assume, you tell them what transport method to use by
using https// or http://.
OK. Let me see if I can explain myself a bit better. You're all correct
that by entering an https:// scheme the _intention_ is to advise the browser
to use a secure layer - which most common browsers do. My point is not that
this is not what should happen, but rather that in many situations the
programmer cannot know in advance what kind of weird server setups may be in
use, and cannot know what kind of client will be accessing them. The fact
that my simple browsers just did telnet server 443 is EXACTLY the point
I'm trying to make. In order to ensure that an SSL layer is actually
active, checking the port OR scheme is not enough. You must actually
query for the presense of the layer itself, which mod_ssl conveniently
provides a means to do by giving us $ENV{HTTPS}.
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: OT: Re: ApacheCon Dublin Cancelled?
On 16 Jul 2001, Randal L. Schwartz wrote: Bill == Bill Moseley [EMAIL PROTECTED] writes: Bill Well, this is more along the price issue that you don't want Bill to hear about, but I much prefer a single fee for everything Bill instead of separate tutorial and conference fees. So you'd rather the overall price be increased, based on the average cost of attending a decent number of the tutorials? Wouldn't that be unfair to those that are attending *just* the conference? Bill I understand the scheduling hell, but I like the flexibility to Bill decide what to attend during the conference. What I attend in Bill the morning may influence what I attend in the afternoon. The problem is materials. Since the tutorials hand out some significant paper, it's hard to decide how much repro to do in advance, unless you know in advance. Also, without enough advance signups, the tutorial speakers themselves need to get cancelled, since they (we :) are an actual hard cost with cutoff deadlines for cancellation. And, how big of a room should you have, if people can just wander in and out? Ah, and the paper issue is one reason why I never submit my materials in advance. It's outrageous to be handing out paper booklets in this modern age. That's something I'd like to see changed in the future: tutorial materials on CD-ROM or Internet only. True, but not everyone brings a laptop :-). With the cellular age coming on, though, I think within a year or two at the most it will be safe enough to assume everyone will have a portable internet connection (eg, Palm or whatever). But untill then, people might want to look at the material during the presentation - very impracticle if the material's only on CD-ROM... Issac
Re: [Probably OT] Make test fails in Net::Telnet
I actually had this problem too. I never found a solution, so in the end I just gave up and force installed. It's also on RH7.1 with perl 5.6.1 I'd be interested in the answer if someone finds it Issac - Original Message - From: Rob Bloodgood [EMAIL PROTECTED] To: mod_perl [EMAIL PROTECTED] Sent: Tuesday, July 24, 2001 19:49 Subject: [Probably OT] Make test fails in Net::Telnet Hi, I'm building a new box intended to be a mod_perl/database machine, and in the interests of making it as up-to-date as possible, I installed RedHat 7.1, then upgraded to perl 5.6.1. Next step, of course, is to hit CPAN and install the basics, starting with Bundle::CPAN. But Net::Telnet barfs on make test. I looked on usenet, and there was a post w/ a guy who had this same problem, but no reply. His post describes the problem clearly: snip From: [EMAIL PROTECTED] ([EMAIL PROTECTED]) Subject: select weirdness/Net::Telnet install barf Newsgroups: comp.lang.perl.modules, comp.lang.perl.misc Date: 2001-06-15 15:21:18 PST On my RedHat 7.1 i586 (laptop) system perl 5.6.1 Net::Telnet won't install using CPAN since 'make test' barfs. The select call to read on a dummy handle returns 1! briefly: socket SOCK, AF_INET, SOCK_STREAM, 0; $bitmask = ''; vec($bitmask, fileno(SOCK), 1) = 1; $nfound = select ($bitmask, undef, undef, 0); $nfound is 1 with SOCK allegedly ready to read! Of course actually reading from it produces a SIGPIPE since it's not connected to anything. The 'socket' 'select' calls themselves don't barf. I'm afraid to force install if there's something deep down wrong w/my select. Any ideas greatly appreciated -thanks! Mark snip [rob@dyn5 /home/rob]$ perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.2-2, archname=i386-redhat-linux uname='linux dyn5.empire2.com 2.4.2-2 #1 sun apr 8 20:41:30 edt 2001 i686 unknown ' config_args='-des -Dcc=gcc -Darchname=i386-redhat-linux -Dcccdlflags=-fPIC - Dccdlflags=-rdynamic -Dprefix=/usr -Dscriptdir=/usr/bin -Dsitelib=/usr/lib/p erl5/site_perl -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 - Dman3ext=3pm -Doptimize=-O2 -march=i386 -mcpu=i686 -Uusethreads -Uuselargefi les -Duseshrplib -Dd_dosuid -Ud_setresuid -Ud_setresgid' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.1 2.96-85)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.2.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.6.1/i386-redhat-linux/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: Built under linux Compiled at Jul 23 2001 17:28:02 %ENV: PERL5LIB=/home/rob/lib/perl5:/home/rob/lib/perl5/site_perl/5.005 @INC: /home/rob/lib/perl5 /home/rob/lib/perl5 /home/rob/lib/perl5/site_perl/5.005 /usr/lib/perl5/5.6.1/i386-redhat-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/i386-redhat-linux/5.6.1 /usr/lib/perl5/site_perl /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl tips? ideas? suggestions? TIA! L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
[OT] Using mod_proxy and mod_ssl to forward SSL connections
I am trying to make a back-end mod_perl/mod_ssl server. The front-end server that is currently in place is doing a great job forwarding normal requests to the back-end, but it is not forwarding SSL. Now, the front-end server does not understand SSL, itself. What I'm doing is trying to force the entire VirtualHost listening on port 443 to an IP on a private subnet on an obscure port (what I do for all the back-end servers. There are actually 3 of them doing various things). But it won't work. The strange thing is that if I go to http://mysite:443/ I get the default Apache It Worked page, but https://mysite/ generates an error saying that the front end cannot understand, which seems to be pointing at the fact that it's not forwarding ANYTHING to the back-end server... Stas Eric: This situation is mentioned in your book, but in nowhere enough detail. IMHO, that segment of the book (near the end of chapter Server Setup Strategies for the Best Performance) should be redone in better detail to explain forwarding SSL to the back-end server. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
The front end server must be configured to understand SSL. Otherwise, how else can the HTTP request be pulled apart (decrypted) to understand that it has to be forwarded to the backend server. 2 words: dumb proxy. The request doesn't need to be pulled apart by the front-end server in this case. The entire virtualhost is supposed to be tunneled directly to the back-end server. That's what I'm trying to figure out how to do... I see. I don't know if that will work. The connect header is a special proxy feature to allow a proxy to just pass through all the TCP level packets instead of opening a separate SSL client connection. But from a reverse proxy perspective, I am not sure that mod_proxy is automatically given this special header by the browser as it might if you configured IE or Netscape to use a physical proxy server. But it definitely won't work based on the HTTP Hostname parameter because SSL has to be established before any other HTTP header other than the weird connect one is decoded. I know :( If you configure the back-end server to understand SSL, that's OK, but beware that all mod_proxy is doing is establishing one SSL connection from browser to mod_proxy and then a brand new SSL connection from mod_proxy to the backend server. 2 separate SSL sessions because SSL cannot (ie inconvenient to) be man-in-the-middled. I know that. The key is (and must be) on the back-end server. Which is why I'm trying to do it this way. The mod_perl book seemed to imply that this was possible, and I _know_ that mod_proxy is supposed to recognize CONNECT requests for this very purpose - it says so in the manual... I just don't know how to set it up properly... It has some likelihood to also to be inefficient because I am not entirely sure that mod_proxy is caching the SSL client session key that it generates to connect to the back-end server as the browser normally does for the front end. I'm not even sure that mod_proxy can be it's own SSL client... The documentation says it knows how to handle incoming CONNECTS, but I'm not sure that it could make its own HTTPS request... If you try it, I think you will find that this works. If you compile in mod_ssl, mod_proxy can establish SSL connections to the back-end. The only thing you lose other than performance is the capability of passing a PKI certificate through the proxy (since decoding and establishing a new SSL connection would be considered a man-in-the-middle attack). I see what you mean. I'm not dealing with client certs (yet), and I'm thinking that when the system that I'm testing now goes production, it'll be a front-end SSL, back-end non-SSL sorta deal... But that won't work for now due to other security issues on the developments boxes... When you don't care about client certificates, it really doesn't matter that the reverse proxy is in the middle because the reverse proxy has the valid server certificate that your client is pre-programmed to understand is a valid certificate (eg from Verisign). Really, the cleanest way of doing what you want is to run the SSL engine on the front-end and then proxy (convert) back the connection to the backend as HTTP. If you are using some authentication on the front-end (eg client certificates) there are modules which will allow you to take a USER_DN and pass it to the back-end server as an addition parameter (eg using mod_rewrite) or as another custom HTTP header. I understand that. It's just not doable for this... In actuality, the back-end server now is not REALLY back-end... The mod_perl server is _behind_ that, so I'm really doing what you're suggesting already :) However, information must still get to this middle-level server, and the top level server certainly can't be trusted to decode sensitive information... Issac PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Bug??
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Chris Rodgers [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, August 01, 2001 05:16
Subject: Re: Bug??
On Tue, 31 Jul 2001, Chris Rodgers wrote:
Thanks for that. However, I've already seen this. The problem is that
I'm
requesting pages at:
http://my.server.com/perl/blah.pl
and also
https://my.server.com/perl/blah.pl
Now these should be different scripts, and Apache is set up with a
completely different document and perl root for the http and https
servers. Unfortunately, these still get confused, even with the
NameWithVirtualHost code. Hence, I thought of hacking the .pm files to
include the server port as well as the name in the uniquely generated
namespace.
Any other ideas??
Hmm, I think you are the first one to hit this issue. Try this (untested):
--- ./lib/Apache/Registry.pm.orig Wed Aug 1 11:06:49 2001
+++ ./lib/Apache/Registry.pm Wed Aug 1 11:11:04 2001
@@ -70,7 +70,8 @@
if ($Apache::Registry::NameWithVirtualHost
$r-server-is_virtual) {
my $name = $r-get_server_name;
- $script_name = join , $name, $script_name if $name;
+ $script_name = join , (exists $ENV{HTTPS}?'https':''),
+$name, $script_name if $name;
}
# Escape everything into valid perl identifiers
based on the earlier discussion about detecting https :)
That will take care of standard http/https, but what if we have a custom
client connecting on weird ports _without_ putting the port in the URL?
Wouldn't it make sense to just take $ENV{SERVER_PORT} and join() _that_ to
make the unique filename? That'll take care of all the weird server
combinations possible including SSL, as only one listening socket can
physically bind to a port. It'll even transparently take care of weird
back-end server problems, as no matter how many servers seem to be on
http://frontend:80, the backends MUST be unique combinations of either
different hostnames or different ports...
Just my $0.02
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Help w/ install [ActivePerl,W2K Server,Apache 1.3.20]
Possible you need an AddModule mod_perl.c line in there somewhere... I'm not such an experienced module-user with Apache for Win32... Issac PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: Brice D Ruth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 07, 2001 00:00 Subject: Help w/ install [ActivePerl,W2K Server,Apache 1.3.20] I'm trying to simply get Apache/mod_perl working in W2K ... I've been trying to follow the steps outlined in messages I've found from searching through archives, but it seems I'm a bit stuck. My experience w/ Apache has always been in Linux or *BSD, so I'm somewhat lost when it comes to getting this going in W2k. I have Apache 1.3.20 installed - the httpd.conf is vanilla - I can access my server by going to http://localhost/ - so all is good there. I downloaded ActivePerl 629 (?) and it installed fine ... c:\perl\bin is in my path and seems to work fine. I ran PPM and had it install mod_perl from theoryx5.uwinnipeg.ca - everything seemed to run fine and in the end it asked me where to put mod_perl.so - the path I gave was c:/Program Files/Apache Group/Apache/modules - I later looked here and I could see mod_perl. I then added the following line to my httpd.conf: LoadModule perl_module modules/mod_perl.so and left everything else as it was. I now get the following when I try to start Apache: The Apache service is starting. Failed to start the Apache service. Note the errors or messages above, and press the ESC key to exit. (countdown)... I don't see any error messages that do me any good, config test returns Syntax OK and the error log shows nothing. What do I need to do? Any help would be greatly appreciated! Brice Ruth
Keeping POST information between request phases
I know this sounds like a rather newbie-ish question, but I guess I never really did many inter-request-phase stuff before... Anyway, how can I keep track of the information from a POST request between different phases of Apache's handling? For example, if I have a $q=new Apache::Request($r); in, say, the Authentication, how can I get the POSTed variables in, say, the Response phase? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: site copies under the one httpd
One solution could be to put your modules in some nonstandard location and include them in @INC in the mod_perl_start.pl. Then just use two different locations for the modules, and each server adds one of these locations into @INC - so production modules go to production server's @INC and dev goes to dev server's @INC... Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: raptor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 17:08 Subject: site copies under the one httpd hi, I have a site, it has two copies one that is on the Dev server (dev-copy) and the other Production one. So what I want ? I want to have the Production site on my dev machine ... ( i'm arraging that the DB and all dependant stuff get copied after some time passes). But AS U KNOW I can't have two different modules with the same name under one mod_perl even if they are on different virtual-hosts, 'cause they get precompiled under the same name... Is the only solution to use differnt mod_perl processes to handle this situation ?!! = iVAN [EMAIL PROTECTED] =
Re: DB_File needs compatible versions
I originally just posted this back to Scott, but after seeing all the flurry of activity regarding this lately, here's my $0.02 on the issue... -Original Message- I've had this problem. The problem is actually in the RPM for perl, whichin it's default make notices this problem and removes db.h from perl. I'vediscovered, however, that you can build perl yourself and simply put db.hback into perl at the end of the ./configure script (right before makingdependancies by editing the config.sh file and adding -ldb to LIBS). After building the(addmittadly possibly mismatched) libdb, perl lets you rebuild it over and over if you so wish, and I've yet to run into problems... Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
[Somewhat OT] Typo in the guide
I actually tried to send this directly to Sats - twice. But mail seemed to be bouncing, so I suppose I'll have to do this through the list... Firstly - the typo: the mod_perl porting page contains info about setting HTTP headers - but the guide says to do $r-headers_out, when the function is $r-header_out (w/o the s). This might also be in the book, which brings me to issue #2: I recently lost my bookmarks, can you please resend the URL to the book - I remember my user/pass (I think so, anyway), but need the URL Thanks, Issac PS. Stas: I think mail bounced because you (or some RBL you use) blacklisted my ISP. The error was "Service unavailable (554 m1.bezeqint.net[192.115.106.45]: Client host rejected: Access denied)" Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
RFC: Apache::UploadMeter
I need to make an upload meter for a project that I'm working on, and was wondering if it was worth making a generic one and puting it under the Apache::* namespace (probably Apache::UploadMeter). The reason that I'm asking is because it's going to need a rather extensive configuration to implement - it needs to use different parts of the request chain for 3 seperate locations (the form with the INPUT FILE tag, the script that processes it, and the location for the "meter"). It will also require several manual additions to the HTML that must be done (to some extent, at least) outside mod_perl (JavaScript code to open a popup browser window to display the "meter"). Do people here think it would be worth building such a tool? I'd love some feedback before I try racking my brains trying to figure out the easiest way to implement this... Thanks in advance. Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Using non-response handler only
Just out of curiosity: are there any efficiency issues regarding using mod_perl for the exclusive use of a phase other than the response? In other words, if I want a script to do something other than return a static page from a file, are there advantages/disadvantages to using mod_perl over C? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Benchmarks on server cluster
I've just recieved an OK to do some Benchmarks on a server cluster of 16+1 (master) dual 450 Mhz machines (master node is dual 650). I plan on doing benchmarks and comparing perfornance for the following setups, so far: Server cluster using httpd process on each individual node and front end round-robin scheme Singe server on master node using MOSIX and high volume of child processes Trying to think of method to test optimal performance on Beowolf type cluster I will also try to play around with different Apache-2 setups if I can figure out how to do so... If people have any suggestions for other things to test, or ways to test it, please let me know. Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Unpredictable Effects after Upload...
I dunno - I recently fixed a problem with the upload_hook that was making a similar problem... Tell me: is there anything weird in the error_log right after the upload? Perhaps the file is not being parsed properly... Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: Jonathan M. Hollin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 31, 2001 14:34 Subject: Unpredictable Effects after Upload... Hello all, Platform: Windows 2000, Apache, mod_perl Problem: When submitting forms that include files (uploads) my script becomes very unpredictable - CGI.pm doesn't seem to be able to recognise any data that's passed as part of the query string (it does still process form input though) once a file has been uploaded. Submit the same form but without attaching a file and everything works perfectly. There is nothing in the error logs to indicate what the problem might by (I'm using the -w flag). Can anyone offer any insight into what might me going on here? Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
[OT] Cookie woes
Hi everyone. This actually isn't mod_perl per se, but I'm hoping that other web developers might know something about this. I'm having cookie problems with, interestingly enough, both Netscape and MSIE. I'm setting a cookie in a page. Included in the page is an inline document (can be anything - CSS, pic, JS, DTD, XSLT - anything loaded inline). The browser requests to the inline pages do NOT include the cookie I've just set. Anyone know why this is, or even better: how to make these inline requests include the cookie? By the way, may as well mention what I'm seeing with both browsers. Netscape's simply not showing anything. MSIE actually does worse - if a cookie's just been expired, it'll send it (the old obsolete cookie) on the inline requests for some dumb reason, but won't send the new one until second time around... Any help would be... well... helpful :-) Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: http or https in URL?
*sigh* Didn't we have this argument out about 2 months ago???
There's an old thread on this and most of what's being said here isn't
adding anything, but rather repeating things... The conclusions were
basically that the best way would be to check $ENV{HTTPS}, but I seem to
recall someone pointing out that this only happens late in the request...
The port check is unreliable as that is only standard ports. Possibly,
there might be some dvantage into seeing if mod_ssl, or another module, can
be configured to set $ENV{HTTPS} a bit earlier in the request if this is
really a problem.
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: Reif Peter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 06, 2001 17:37
Subject: http or https in URL?
In a mod_perl handler I want to construct the original URL of the request.
I
can construct it with r-get_server_name, r-get_server_port, r-uri and
$r-parsed_uri-query.
But how do I get the protocol, http or https. Is there a way to find out
whether SSLEngine On is set?
Yes, I can set it with PerlSetVar protocol https, but is there a simpler
way?
Thanks in advance,
Peter
--
/\ ASCII Ribbon Campaign
\ /
X Against HTML
/ \ in e-mail news
Apache::OutputChain vs. Apache::Filter
Just out of curiosity, which of these two modules are more popularly used? I have to make some sort of inline SSI processing in one of my modules, and am curious to know how other people do it... I know that different people will do different things depending on the situation, and that there's really no "Generic" answer, but am still curious to hear how others do this kind of thing... Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
$r-set_handlers and $R-push_handlers
How can you specify a Location for these paramters, or can they be used only from within the current section? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Perl sections from within a module
Is there a way of doing configuration work (the equivalent of Perl sections) from within modules? I ask both for subroutines which are called at server startup (from mod_perl_start.pl) and from other handlers... Thanks in advance, Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: array's first element is empty
I don't think this is OT. I have had a similar error in which SELECT statements return fine under mod_cgi, but mysteriously get an extra null field underl mod_perl with Apache::DBI... I don't know what causes it, nor have I looked into it, but I think it is somewhat related to or caused by mod_perl or some of its' modules... Issac PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: Joshua Chamas [EMAIL PROTECTED] To: Viljo Marrandi [EMAIL PROTECTED] Cc: modperl list [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 1:19 Subject: Re: array's first element is empty Viljo Marrandi wrote: Hello, Not sure if this is mod_perl related, but i hope someone can help me anyway. When i do DBI queries from mod_perl handler and put all returned results in array then array's first element is empty, I wonder why? I don't like to shift off first element every time i return the result. Has anyone seen this before and what could cause this? This is off topic for mod_perl, and should as such either not be posted, or posted with a [OT] in the beginning of the subject line. The DBI mailing lists would be of greater help, listed here at: http://www.isc.org/services/public/lists/dbi-lists.html To answer your question, a query like: select nothing,something from table would have a undef value returned from the nothing column if the data in that column were NULL. You probably should remove the nothing column from your query instead of shifting the results. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: array's first element is empty
Well, I don't want to cry wolf (or Bug in this case). I wasn't going to bring it up except that this was getting shoved off of mod_perl, and I didn't think that it should... I'm not going to cry bug unless I can back it up - it just might be a fluke coincidence - I don't know. I just wanted to let people know. Issac PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: Joshua Chamas [EMAIL PROTECTED] To: Issac Goldstand [EMAIL PROTECTED] Cc: Viljo Marrandi [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 1:38 Subject: Re: array's first element is empty Issac Goldstand wrote: I don't think this is OT. I have had a similar error in which SELECT statements return fine under mod_cgi, but mysteriously get an extra null field underl mod_perl with Apache::DBI... I don't know what causes it, nor have I looked into it, but I think it is somewhat related to or caused by mod_perl or some of its' modules... This sounds like it might be a bug then, and I might bring it up on the DBI list and see if there is a solution. It might be that something in the glue of Apache::DBI is causing this problem too, but would doubt that, as I believe this glue only overrides behavior for connect/disconnect. Note that I have never seen this bug, working with Oracle mysql under various perls mod_perl builds, so you might look at your particular software versions as having the problems, or even your particular database driver ( DBD::* ) for the problem. Also, sometimes DBD::* drivers are guided by %ENV settings, like Oracle, so make sure that your mod_perl has the same %ENV as your when running under mod_cgi. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Apache::Request UPLOAD_HOOK
The documentation on how to use this feature is a bit sketchy... Can anyone explain: 1) What the variables passed to the callback function are (looks like the Apache::Upload object is the first, but what's been filled in there when the hook gets called? The second looks like the current bunch of data that's been recieved[?], the third is the length, but is that the length recieved so far or the length recieved between the last time it was called and this time? And lastly, what can be placed in HOOK_DATA - scalar only?) 2) Is there any way of knowing how often the hook will get called? 3) Is there a specific phase of the Request that Apache::Request must be called and initialized with the callback before? 4) Are there any specific issues for using this with Apache::Request-instance ? Thanks, Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Apache::Request UPLOAD_HOOK
OK. I get all that. Now I'm getting a very strange error when I try to use
the hook. the error from the error_log is: Undefined subroutine
Apache::Upload::handler called at /dev/null line 1.
Here is the code that calls the hook:
sub header_parser_handler($)
{
my $=shift;
my $hook_handler= sub {
my ($upload, $buf, $len, $hook_data)=@_;
$hook_cache-set($hook_data,$len);
Apache-log_error($hook_data: got $len bytes for .$upload-name);
};
my %cookies=Apache::Cookie-fetch;
my $u_id=$cookies{u_id}-value;
my
$q=Apache::Request-instance($r,TEMP_DIR=/home/www/spool,HOOK_DATA=$u_i
d,UPLOAD_HOOK=$hook_handler);
return OK;
}
Any idea what's going on here?
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: Joe Schaefer [EMAIL PROTECTED]
To: Issac Goldstand [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, October 08, 2001 19:16
Subject: Re: Apache::Request UPLOAD_HOOK
Issac Goldstand [EMAIL PROTECTED] writes:
The documentation on how to use this feature is a bit sketchy...
Yes, I agree. Doc patches are always welcome.
Comments below are from memory since I last tested this feature
about 6 months ago.
Can anyone explain: 1) What the variables passed to the callback
function are (looks like the Apache::Upload object is the first, but
what's been filled in there when the hook gets called?
The current upload object goes there when the hook is called.
The second looks like the current bunch of data that's been
recieved[?],
Right, it's the buffer from apache's ap_get_client_block,
which is usually around 2-4 KB. The hook runs before the
buffer gets written to the underlying tempfile, but as soon
as your hook has completed, Apache::Request will write it
automatically.
the third is the length, but is that the length recieved so far or the
length recieved between the last time it was called and this time?
The length of the buffer; the same as length($buffer).
And lastly, what can be placed in HOOK_DATA - scalar only?)
Yes, but the scalar can also be a ref to an array or hash.
2) Is there any way of knowing how often the hook will get called?
Not really- it's called when apache calls ap_get_client_block.
3) Is there a specific phase of the Request that Apache::Request
must be called and initialized with the callback before?
The hooks get run as the data is uploaded to the server,
which IOW is when the data is first being parsed. This
can happen at any phase you choose, but it only happens
once per request.
4) Are there any specific issues for using this with
Apache::Request-instance ?
Other than (3), I don't think so- but as I said before
this is not a well-tested feature (yet :)
HTH
--
Joe Schaefer
Re: Problem with Apache-request
Try doing my $r=Apache::Request-new($r);
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: Randy Rasmussen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 18:35
Subject: Problem with Apache-request
I am having a problem with a module that needs Apache-request.
The module is AuthCookieLDAP. I have a .htaccess (/test2/.htaccess) file
that looks like:
AuthType Apache::AuthCookieLDAP
AuthName SA
PerlAuthenHandler Apache::AuthCookieLDAP-authenticate
PerlAuthzHandler Apache::AuthCookieLDAP-authorize
require valid-user
That in turn reads my httpd.conf file which has the following:
Files LOGIN
AuthType Apache::AuthCookieLDAP
AuthName SA
SetHandler perl-script
PerlHandler Apache::AuthCookieLDAP-login
/Files
PerlModule Apache::AuthCookieLDAP
PerlSetVar SAPath /
PerlSetVar SALoginScript /cgi-bin/login.pl
PerlSetVar SALDAP_DN o=isp
PerlSetVar SADBI_DSN isp
PerlSetVar SALDAP_SecretKeyFile .../apache/foobar.com.key
PerlSetVar SALDAP_User tesuser
PerlSetVar SALDAP_host host.foobar.com
#PerlSetVar SALDAP_host ldap.foobar.com
PerlSetVar SALDAP_EncryptionType none
PerlSetVar SALDAP_SessionLifetime 00-24-00-00
Then it runs the login.pl script which looks like:
#!/usr/bin/perl
#
# $Id: login.pl,v 1.1 2000/07/11 17:03:05 jacob Exp $
use strict;
use 5.004;
use Text::TagTemplate;
use Apache;
my $t = new Text::TagTemplate;
my $r = Apache-request();
my $destination;
my $authcookiereason;
if ( $r-prev() ) { # we are called as a subrequest.
$destination = $r-prev()-args()
? $r-prev()-uri() . '?' . $r-prev-args()
: $r-prev()-uri();
$authcookiereason = $r-prev()-subprocess_env(
'AuthCookieReason' );
} else {
$destination = $r-args( 'destination' );
$authcookiereason = $r-args( 'AuthCookieReason' );
}
$t-add_tag( DESTINATION = $destination );
unless ( $authcookiereason eq 'bad_cookie' ) {
$t-template_file( ../html/login.html );
} else {
$t-template_file( ../html/login-failed.html );
}
$r-send_http_header;
print $t-parse_file unless $r-header_only;
When I go to /test2/index.html I get this error:
Can't locate object method request via package Apache at
.../cgi-bin/login.pl line 16.
[Wed Oct 10 10:43:26 2001] [error] [client 172.28.22.253] Premature end
of script headers: .../cgi-bin/login.pl
Here is the software and versions I have installed:
apache 1.3.20, Apache-AuthCookie-3.00, Apache-AuthCookieLDAP-0.02,
mod_perl-1.26, perl5.005_02
Please help. I have looke all over deja.com, and all of the perl and
mod_perl sites I can think of to no avail.
Thanks in advance,
Randy
libapreq returning very strange error
I recently tried to use some of what I've tried to
learn about the UPLOAD_HOOK provided via Apache::Request. However, when
using it, I get a really weird error:
Undefined subroutine
Apache::Upload::handler called at /dev/null line 1.
Anyone know what would be causing this error (and,
by the way, where the reference to /dev/null is coming from)?
Here's the function that provides the
hook:
my
$r=shift; ### Upload hook handler
my $hook_handler= sub
{ my ($upload, $buf, $len,
$hook_data)=@_;
$hook_cache-set($hook_data,$len);
Apache-log_error("$hook_data: got $len bytes for
".$upload-name); };
my
%cookies=Apache::Cookie-fetch; return BAD_REQUEST
unless defined($cookies{u_id}); my
$u_id=$cookies{u_id}-value; my
$q=Apache::Request-new($r, HOOK_DATA=$u_id,
UPLOAD_HOOK=$hook_handler,
TEMP_DIR="/home/www/spool"); return
OK;
The TEMP_DIR is there because the file will be
saved to /home/www/files and /home/www is the mount point for the HD
partition.
Thanks,
Issac
Internet is a wonderful mechanism for making a fool
ofyourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into
trouble... Clicking it might. --Anonymous
PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623
A57B 7F37 D902 8C84 7675 E0FA 561B
libapreq problem: solved
Apparantly, I made a major mistake with the UPLOAD_HOOK error... While it still doesn't work, I found out what caused the mysterious error... The name space I happen to be using is TFile::*, and all of my upload-related handlers are stuffed into TFile::Upload. Unfortunately, out of force of habit, in the httpd.conf for the upload location, I did PerlHandler Apache::Upload instead of TFile::Upload... Sorry, guys :-( *hits himself in the head for everyone* Woefully yours, Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
More libapreq woes...
I've made some progress since my stupid and, admitedly, rather careless,
error with the upload_hook extended by libapreq. I finally gave up on
debugging it in it's current context and made a seperate light module setup
just to test. Currently, I'm using the Apache::Test::UploadMeter namespace
(if this all works, I suppose I'll copy this project to CPAN under the
Apache::UploadMeter namespace). In any case, here's what I've got so far:
Apache/Test/UploadMeter.pm
---
package Apache::Test::UploadMeter;
use strict;
use warnings qw(all);
use diagnostics;
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
use Apache;
use Apache::Constants qw(OK DECLINED HTTP_MOVED_TEMPORARILY BAD_REQUEST
NOT_FOUND);
use Cache::FileCache; # For Win32 compatibility - required for IPC from
upload_hook to upload_meter
BEGIN {
use Exporter ();
$VERSION=0.01;
@ISA=qw(Exporter);
@EXPORT=();
@EXPORT_OK=qw ( );
%EXPORT_TAGS=();
}
### Version History
# 0.01 : Oct 14, 2001 - Started
### Globals
my
%cache_options=('default_expires_in'=900,'auto_purge_interval'=60,'namespa
ce'='u_hook'); #If the hooks don't get called in 15 minute, assume it's
done
sub handler
{
my $r=shift;
### Upload hook handler
my $hook_handler=sub {
my ($upload, $buf, $len, $hook_data)=@_;
Apache-log_error($hook_data: got $len bytes for .$upload-name);
};
my $q=Apache::Request-instance($r,
HOOK_DATA=hardcoded,UPLOAD_HOOK=$hook_handler,
TEMP_DIR=/home/www/spool);
my $file=$q-upload;
my $fname=$file-filename;
$r-send_http_header('text/plain');
$r-print(done\n\n$fname);
return OK;
}
1;
__END__
httpd.conf
---
Location /test
SetHandler perl-script
PerlHandler Apache::Test::UploadMeter
/Location
When doing an upload from a blank HTML page (just a form with an upload
field), I get the following output in the browser:
done
D:\EXPORTS\Log.txt
...and the following output in error_log:
[Sun Oct 14 16:49:12 2001] [error] [client 192.168.1.1] request failed:
error reading the headers
Something's obviously not working right. The only clue I have is that the
error is _definately_ caused by the upload hook, because when I remove that
from the code, I get no errors in error_log. Any help on this would be
appreciated...
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: file upload process
Also, I'm currently putting the finishing the final touches on a module called Apache::UploadMeter which automates this process pretty well... Help is more than welcome - at this point, the internals are really done. It's just an issue of making a configuration interface, a bit of documentation, and sending it to CPAN... Issac - Original Message - From: Geoffrey Young [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 04, 2001 17:54 Subject: RE: file upload process -Original Message- From: El Capitan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 10:46 AM To: [EMAIL PROTECTED] Subject: file upload process [snip] Is there some way to capture the download stream (when its actually downloading) and begin a display process back to the customer? I haven't used it, but recent versions of libapreq support the UPLOAD_HOOK parameter to Apache::Request-new(). see the Apache::Request manpage --Geoff
Apache::can_stack_handlers()
What version of mod_perl starts supporting this? Issac -- Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Pushing Handlers from Perl sections
Can I _upsh_ handlers from within Perl sections? If so, how? Issac -- Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
using Apache::ReadConfig to configure from perl scripts
Hi all... I'm trying to put the finishing touches on
Apache::UploadMeter, but am running into a minor problem. Due to the
complexity of the configuration, I'm trying to use the
Apache::ReadConfig namespace from mod_perl_start.pl to dynamically
configure the upload-meter (by setting some variables in the
Apache::UploadMeter namespace and then calling a configure() routine).
Enclosed is the configure() subroutine. It runs fine, but doesn't seem
to be tying the handlers properly. Any advice would be helpful. Also,
if anyone know how I could dynamicly add handlers to the stack directly
from the Apache::ReadConfig namespace without knowing in advance what
other handlers are enabled for a given Location, that would be helpful...
Issac
sub configure()
{
my $namespace=__PACKAGE__;
my
($UploadScript,$UploadMeter,$UploadForm)=(_conf(UploadScript),_conf(UploadMeter),_conf(UploadForm));
warn Config $UploadScript - $UploadMeter - $UploadForm - in
namespace $namespace if (_conf(DEBUG)1);
package Apache::ReadConfig;
no strict;
$Location{$UploadScript} = {
SetHandler = 'perl-script',
Options = '+ExecCGI',
#PerlHeaderParserHandler = $namespace.::u_handler,
#PerlFixupHandler = $namespace.::ufu_handler,
PerlHeaderParserHandler = $namespace.::jit_upload,
};
$Location{$UploadMeter} = {
SetHandler = 'perl-script',
Options = '+ExecCGI',
#PerlHandler = $namespace.::um_handler,
PerlHeaderParserHandler = $namespace.::jit_meter,
};
$Location{$UploadForm} = {
Options = '+ExecCGI',
SetHandler = 'perl-script',
#PerlFixupHandler = $namespace.::s_h,
#PerlTransHandler = $namespace.::uf_handler,
PerlHandler = $namespace,
PerlInitHandler = $namespace.::s_h,
};
return 1;
}
sub _conf($)
{
my $arg=shift;
warn (Extracting $argeval(\$.__PACKAGE__.::.$arg)) if
(eval(\$.__PACKAGE__.::DEBUG 1));
return eval(\$.__PACKAGE__.::.$arg);
}
--
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: using Apache::ReadConfig to configure from perl scripts
Well, I'm getting some of the stuff to work... Just not all three Locations and I can't figure out what keeps breaking. It's really weird... When I had the first two handlers set to PerlInitHandler and the third to PostReadRequestHandler (Which ought not work in a Location) only the third works, yet when I try setting them all to PostReadRequestHandler, NONE of them work... I'm really quite lost and would appreciate any help anyone could offer about setting perl handlers in Perl sections in general Issac Geoffrey Young wrote: Issac Goldstand wrote: Hi all... I'm trying to put the finishing touches on Apache::UploadMeter, but am running into a minor problem. Due to the complexity of the configuration, I'm trying to use the Apache::ReadConfig namespace from mod_perl_start.pl to dynamically configure the upload-meter (by setting some variables in the Apache::UploadMeter namespace and then calling a configure() routine). Enclosed is the configure() subroutine. It runs fine, but doesn't seem to be tying the handlers properly. Any advice would be helpful. Also, if anyone know how I could dynamicly add handlers to the stack directly from the Apache::ReadConfig namespace without knowing in advance what other handlers are enabled for a given Location, that would be helpful... I tried something similar in this (highly experimental and unfinished) module http://www.modperlcookbook.org/~geoff/modules/Apache-ReverseLocation-0.01.tar.gz maybe looking that module over would be of some help... had I the inclination, I would use the qr// operator to properly fix the Alias bit, and do something better about the vhost problem, and... at any rate, overriding Location and friends is a cool way to know what Locations are in your httpd.conf... HTH --Geoff -- Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: [VERY OT] How to Use Apache as a FTP server
That's not mod-perl. That's not even Apache. Many popular web browsers have browsing features for anonymous FTP. You need an FTP server for that. Apache 2 will include an FTP server (I think), but for now, try wuftpd. Issac anandr wrote: Hi All, I want to use my Apache as a ftp service also. Can the ring help me. I am running Apache 1.3.22 at port 80. when I give http://servername/, I get the list of files in my htdocs. Like wise when I give ftp://servername/, I need a list from my server folders. Have look at this address,for what I am intending to do,..ftp://tiger.com. With Regards, Anand Ratnasabapathy, DSM Soft(P)Ltd, No:25,Nungambakkam High Road, Chennai - 600 034. http://www.dsmsoft.com -- Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: irc
Thomas Eibner wrote: On Sat, Dec 22, 2001 at 07:21:00AM -0800, brian moseley wrote: i can't believe i never thought to ask this in 4 years, but: do any of you hang out on irc anywhere in particular? shouldn't there be a #mod_perl somewhere, if there isn't already? We used to hang on #Take23 on Openprojects for a while, but it kinda died out.. Some of us still do. IMHO, suggesting new a channel isn't going to get more regulars... If you want the channel, hang out there. That's the only way it'll work (we're at irc.openprojects.net, #take23) Issac -- Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
[ANNOUNCE (sort of)] Apache::UploadMeter-0.15
Since I'm still waiting after a month for a PAUSE account (apparantly there's some major hold-up at [EMAIL PROTECTED]), I've released Apache::UploadMeter on sourceforge.net The project homepage is http://sourceforge.net/projects/apache-umeter Version 0.15 is out, but it's still Alpha, since I'm still having trouble getting the configuration to work properly, but due to the fact that I haven't had the time to give it proper attention, I decided to release it anyway, and if anyone wants to patch it for me, I'll make a working Beta release of it. Questions/Comments welcome. Issac
Smart Web Apps with IPC and threading
Since I started work on Apache::UploadMeter, I've started to look into the possibilities of creating smarter and more user-interactive webapps using IPC between webserver processes. Basically, the way this works is that you can open a magic URL at form submission/link-click time, which can be tied to a slave server, which can be instructed to provide any type of realtime feedback that you'd like - in the case of Apache::UploadMeter, the magic URL displays a snapshot of the upload process and reloads itself every X seconds, but form submissions can be done with this too. The problem is that under Apache 1.3, that wouldn't work well due to the fact that each child process is just that: a standalone process. And that's going to tie up a lot of servers and child processes, and basically make a big mess. However, under the Apache 2 threading MPM, this wouldn't seem to be a problem - especially if there is good shared resources between the threads. And mod_perl shouldn't be a problem either, as long as shared perl interpreters are used... So basically, I'd like to know if other people have any ideas that they'd be interested in sharing, and just basically see if we could look at some of the new ways of designing webapps like this. Looking forward to getting feedback, Issac PS. I posted to this list because I'd like to hear from mod_perl users - not just developers or advocates - but if this gets way OT, let's move this thread to the appropriate place.
Re: HTTP file uploads with mod_accel
I use it with uploads and it all works fine. What I still haven't tested is the UPLOAD_HOOK functionality of Apache::Request under it, but I'll get around to that shortly. Issac Philip Mak wrote: Has anyone been using mod_accel on a website that has HTTP file uploads? I'm having trouble getting file uploads to work with Internet Explorer 5.5, Netscape 4.7, or Opera 6 through mod_accel 1.0.10. If I access the backend Apache directly, it works. I can upload a 1491 byte file, but I can't upload a 13643 byte file (no matter which web browser I use). When I try to upload the 13643 byte file through mod_accel, the browser just keeps acting like it's loading the page and never finishes. I'm guessing there might be a buffering problem, but I'm not sure how to go about finding the cause of the problem and fixing it... any suggestions?
Re: Fixed (Re: HTTP file uploads with mod_accel)
Igor, DOES mod_accel buffer the uploads as they come through? That feature would be critical for compatibility with libapreq's UPLOAD_HOOK, which I'm finding lots of nice uses for... Issac - Original Message - From: Igor Sysoev [EMAIL PROTECTED] To: Philip Mak [EMAIL PROTECTED] Cc: Issac Goldstand [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 06, 2002 6:56 PM Subject: Re: Fixed (Re: HTTP file uploads with mod_accel) On Sun, 6 Jan 2002, Philip Mak wrote: Never mind, I'm an idiot. I just took a look at the error_log of my frontend and the problem became clear. [Sun Jan 6 09:42:04 2002] [error] [client 206.173.36.189] (13)Permission denied: accel: can't create tempfile /usr/local/apache/cache/tmpFtYxlf My fault. I've just fixed it and in next release mod_accel would return 500 in this case. Igor Sysoev
[ANNOUNCE] Apache::UploadMeter-0.15
Finally, after a month of being bogged down on [EMAIL PROTECTED], the barriers have being cleared and Apache::UploadMeter's hit CPAN! The URL http://telia.dl.sourceforge.net/apache-umeter/Apache-UploadMeter-0.15.tar.gzhas entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-UploadMeter-0.15.tar.gz size: 5781 bytes md5: 635457cab775fa4c169d74180b9219f6No action is required on your partRequest entered by: ISAAC (Isaac Goldstand)Request entered on: Tue, 08 Jan 2002 06:04:40 GMTRequest completed: Tue, 08 Jan 2002 06:05:08 GMT Issac
Re: [ANNOUNCE] Apache::UploadMeter-0.15
Eventually, yes, but unfortunately not yet. Until the configuration for _one_ meter isn't 100% stable, I'm not going to set up multiple meters. But it is the first thing on the ToDo list after it becomes stable. Issac eCap wrote: So if I have two different html forms that perform uploads, can I define two different forms in the httpd.conf file? -Original Message- *From:* Issac Goldstand [mailto:[EMAIL PROTECTED]] *Sent:* Monday, January 07, 2002 10:08 PM *To:* [EMAIL PROTECTED] *Subject:* [ANNOUNCE] Apache::UploadMeter-0.15
[ANNOUNCE] Apache::UploadMeter-0.17
The URL http://prdownloads.sourceforge.net/apache-umeter/Apache-UploadMeter-0.17.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-UploadMeter-0.17.tar.gz size: 6182 bytes md5: 184038fd7ce8255c1591f0ec4f5eff25 No action is required on your part Also available on SourceForge (see above URL). SourceForge project homepage http://sourceforge.net/projects/apache-umeter Issac
RFC: Thumbnail generator
I recently decided that Apache::Gallery is really nice if you want to sit down and start fiddling with templates, but that I needed to make a quick-easy version for myself. The design is to be extremely simple, and is divided into two seperate modules. The first is an on-the-fly thumbnail generator (currently supports only jpeg), which is just a spiced up implementation of Image::GD::Thumbnail. The second is a directory index generator, which displays each file name and a link to the picture, using URIs to the on-the-fly thumbnail generator to show the previews. Ideas are welcome, but my main questions are: 1) Put it on CPAN? 2) Namespace? Issac
Re: Thumbnail generator
Robert Landrum wrote: At 4:13 PM +0100 1/21/02, Gerald Richter wrote: I recently decided that Apache::Gallery is really nice if you want to sit down and start fiddling with templates, but that I needed to make a quick-easy version for myself. The design is to be extremely simple, and is divided into two seperate modules. The first is an on-the-fly thumbnail generator (currently supports only jpeg), which is just a spiced up implementation of Image::GD::Thumbnail. You may want to take a look at Apache::ImageMagick (if you not already have). It's let's you create thumbnails very easy (just two parameters pic.xxx/scale?geometry=100x100) and ImageMagick supports over 80 different formats. It also handles conversion from 4 color pictures to RGB for your thumbnails and many other things, if you need them. ImageMagick is way too slow for use in a production system. Especially if your resizing large images into thumbnails. I suggest sacrificing space for speed and pre-generating all your thumbnails. Most of the time libjpeg will do everything you need, including scaling. I suggestion GD with Jpeg support or Inline.pm/C/libjpeg for real time conversion of jpegs. There are probably other faster libs out there, and I'm just citing the ones I've heard about or used in the past. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI. Part of the idea here is to do everything on-the-fly so that changes on the filesystem (in terms of adding/removing pictures) will IMMEDIATELY take effect (including caching, etc) on the web interface. That means no thumbnails to start with. Issac
[ANNOUNCE] Apache::GD::Thumbnail-0.01
The uploaded file Apache-GD-Thumbnail-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-GD-Thumbnail-0.01.tar.gz size: 2428 bytes md5: 5c46eca45e213e98a2d2388b7a6fcb8a NAME Apache::GD::Thumbnail - Apache module which generates on- the-fly thumbnails using GD and libjpeg SYNOPSIS Location /pics/thumbnails SetHandler perl-handler PerlHandler Apache::GD::Thumbnail PerlSetVar ThumbnailMaxSize 75 PerlSetVar ThumbnailBaseDir /usr/local/httpd/htdocs/pics /Location DESCRIPTION Just what it looks like: creates on-the-fly thumbnails of a jpeg image. There are two optional configuration direc tives. · ThumbnailMaxSize Sets the maximum number of pixels to be used in the thumbnail for length or width (whichever is larger) · ThumbnailBaseDir Sets the directory that contains the images to be thumbnailed. Defaults to .. if not set. AUTHOR AND COPYRIGHT Copyright (c) 2002 Issac Goldstand - All rights reserved. This library is free software. It can be redistributed and/or modified under the same terms as Perl itself.
Re: performance coding project? (was: Re: When to cache)
Ah yes, but don't forget that to get this speed, you are sacrificing
memory. You now have another locally scoped variable for perl to keep
track of, which increases memory usage and general overhead (allocation
and garbage collection). Now, those, too, are insignificant with one
use, but the significance will probably rise with the speed gain as you
use these techniques more often...
Issac
Stas Bekman wrote:
Rob Nagler wrote:
Perrin Harkins writes:
Here's a fun example of a design flaw. It is a performance test sent
to another list. The author happened to work for one of our
competitors. :-)
That may well be the problem. Building giant strings using .= can be
incredibly slow; Perl has to reallocate and copy the string for each
append operation. Performance would likely improve in most
situations if an array were used as a buffer, instead. Push new
strings onto the array instead of appending them to a string.
#!/usr/bin/perl -w
### Append.bench ###
use Benchmark;
sub R () { 50 }
sub Q () { 100 }
@array = ( x R) x Q;
sub Append {
my $str = ;
map { $str .= $_ } @array;
}
sub Push {
my @temp;
map { push @temp, $_ } @array;
my $str = join , @temp;
}
timethese($ARGV[0],
{ append = \Append,
push = \Push });
Such a simple piece of code, yet the conclusion is incorrect. The
problem is in the use of map instead of foreach for the performance
test iterations. The result of Append is an array of whose length is
Q and whose elements grow from R to R * Q. Change the map to a
foreach and you'll see that push/join is much slower than .=.
Return a string reference from Append. It saves a copy.
If this is the page, you'll see a significant improvement in
performance.
Interestingly, this couldn't be the problem, because the hypothesis
is incorrect. The incorrect test just validated something that was
faulty to begin with. This brings up you can't talk about it unless
you can measure it. Use a profiler on the actual code. Add
performance stats in your code. For example, we encapsulate all DBI
accesses and accumulate the time spent in DBI on any request. We also
track the time we spend processing the entire request.
While we are at this topic, I want to suggest a new project. I was
planning to start working on it long time ago, but other things always
took over.
The perl.apache.org/guide/performance.html and a whole bunch of
performance chaptes in the upcoming modperl book have a lot of
benchmarks, comparing various coding techniques. Such as the example
you've provided. The benchmarks are doing both pure Perl and mod_perl
specific code (which requires running Apache, a perfect job for the
new Apache::Test framework.)
Now throw in the various techniques from 'Effective Perl' book and
voila you have a great project to learn from.
Also remember that on varous platforms and various Perl versions the
benchmark results will differ, sometimes very significantly.
I even have a name for the project: Speedy Code Habits :)
The point is that I want to develop a coding style which tries hard to
do early premature optimizations. Let me give you an example of what I
mean. Tell me what's faster:
if (ref $b eq 'ARRAY'){
$a = 1;
}
elsif (ref $b eq 'HASH'){
$a = 1;
}
or:
my $ref = ref $b;
if ($ref eq 'ARRAY'){
$a = 1;
}
elsif ($ref eq 'HASH'){
$a = 1;
}
Sure, the win can be very little, but it ads up as your code base's
size grows.
Give you a similar example:
if ($a-lookup eq 'ARRAY'){
$a = 1;
}
elsif ($a-lookup eq 'HASH'){
$a = 1;
}
or
my $lookup = $a-lookup;
if ($lookup eq 'ARRAY'){
$a = 1;
}
elsif ($lookup eq 'HASH'){
$a = 1;
}
now throw in sub attributes and re-run the test again.
add examples of map vs for.
add examples of method lookup vs. procedures
add examples of concat vs. list vs. other stuff from the guide.
mod_perl specific examples from the guide/book ($r-args vs
Apache::Request::param, etc)
If you understand where I try to take you, help me to pull this
project off and I think in a long run we can benefit a lot.
This goes along with the Apache::Benchmark project I think (which is
yet another thing I want to start...), probably could have these two
ideas put together.
_
Re: New mod_perl Logo
Jay Lawrence wrote: I looked at some of the candidates at http://wypug.digital-word.com/mod_perl/ must confess I am partial to http://wypug.digital-word.com/mod_perl/logos/louise_bramald_1.jpg so far Thinking camels for Perl and feathers for Apache putting them together all I could see is flying camels - is that too close to flaming logos? That's my 0.02CAD which is substantially less than 0.02USD... ;-) J I really don't want to see this topic going out of control, but I had to add something here: didn't we have a discussion about this months ago? I seem to remember an idea of a camel with a headband with the Apache feather... I'm sure that's not my own idea. Issac
[ANNOUNCE] Apache::UploadMeter-0.21
The URL http://prdownloads.sourceforge.net/apache-umeter/Apache-UploadMeter-0.21.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-UploadMeter-0.21.tar.gz size: 7293 bytes md5: c2b830b7a6204d40050946c5d84c9583 Also available on SourceForge (see above URL). SourceForge project homepage http://sourceforge.net/projects/apache-umeter Issac Release Notes ChangeLog: *Notes:* The following Perl libraries are now required: Format::Number Format::Date I hope to remove these dependancies as soon as I can get formatting done in XSL *Changes:* UploadMeter_port.patch: Adds the port number to the generated Refresh URL UploadMeter_finished.patch: Stops the Meter from Refreshing endlessly when the upload is complete UploadMeter_starttime.patch: Adds the time the upload started to the output to allow upload rate calculations (Patches submitted by Cees Hek ) ### XSLT + XML Patch submitted by Cees Hek Started migrating internal calculations to XSLT Updated Schema (switch from DTD to xsd) ### 0.21 : Feb 3, 2002 - Prebundled basic skin on sourceforge. Migrate from DTD to schema. Time/Date formatting currently server-side.
Re: mod_perl + UNIVERSAL
Jean-Michel Hiver wrote: [snip] A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. The alternative is having Apache reload the entire module from scratch on every request - and then you may as well be using mod_cgi.. [snip] * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... These are the - painful - issues I discovered during the last 6 month of intensive mod_perl coding. I hope they'll be fixed at some point because mod_perl could be so popular if they were! I dunno... I think that the main reason mod_perl isn't as popular as mod_php is because PHP is SSI based, making it more appetizing to lots of developers who don't have such good access to the server, or who don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing modules and having to reload the server (or use a top-heavy module like Apache::StatInc) every time you want to change your code. Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Just my two agorot (a bit less than $0.005 now, I think, although due to that the smallest currency here is actually _5_ agorot :-) ) Issac
Re: mod_perl + UNIVERSAL
Jean-Michel Hiver wrote: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... Consider this. I develop a piece of software in Perl which is quite big. Therefore it's split into a horde of modules. Now do these modules changes between versions? Yes (bug fixes, improvements, API changes, etc). Do the modules name change? Nope! As a result I had to amend the software so that it can run multiple websites. But then if there is a need to change the logic of just one site I can't just go and change one module because it would change it for everything else. In other words it'd be nice to be able to run different versions of the same software for different websites on the same server (via virtual hosts). And that doesn't work. TMTOWTDI: Make all of your global (base) functionality wrapped into some OO Perl module, and then if you need to change specific behavior for certain apps, you can easily subclass it. If the main functionality has to be changed, change the parent object; if it has to be changed for a specific web-app, dump it into the inheritted class. That's one solution, and I'm sure there are others... Besides this: with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... is highly bullshit. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. The developer does not want to rename his module (I understand that). Even if I install / compile the module locally, mod_perl is going to screw everything up! Great! That's the developer's fault. I'm sorry. But that's why you're _supposed_ to check in with [EMAIL PROTECTED] before deciding on your modules namespaces. Just because _another_ developer is using a taken namespace doesn't make it right enough that special pains have to be made to get around it. And if they _did_, that would be a Perl problem, not a mod_perl related issue! For example, how would you get the CPAN Html::Tree to work in the same script as this other HTML::Tree? You couldn't, because the Perl interpreter wouldn't know what to do with it. Same here! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. I think this is wrong. Variables should be reinitialized by default, or persistent if specified otherwise in some config file. What if I _want_ a variable that stays consistant across a specific child process' lifetime? Right now, a way _exists_ of resetting variables, but how would you propose to keep them static if your idea was implemented? * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... intentional functionality. I though that bugs were called features, but this is even better. I'll have to remember this one :- ;-) don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing True, however the real point of Apache::Registry is to run unaltered CGI scripts under mod_perl and it just doesn't work properly does it? No. That's Apache::PerlRun. Apache::Registry usually needs some tweaking to run properly. There's plenty of information about that in the guide under the HUGE portion devoted to CGI_to_mod_perl_porting (or even in the special manpage under the same name). Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Do you know where to find mod_perl 2 related info on the web? I'd be interested in knowing what's it gonna be. Not really sure. I asked about that and got the current state of the mod_perl 2 docs from CVS, but I, too,
Re: Cookie as session store
Perrin Harkins wrote: When the cookie is recovered, I simply decode, uncompress, thaw, check the digest, and thaw the inner object. It's really a good idea to do this even when the cookie is nothing but a session ID. A standard module for this like the one Jay mentioned would definitely be nice. I dunno... That sounds lie a LOT of overhead for just a session ID that's gonna result in server lookups too... Issac
Re: Image Magick Alternatives?
Ooh!!! Ooh!!! *jumps to publicize his module in a desperate attempt to find someone who might actually NEED it* [So I'm shameless... So what? :-)] Apache::GD::Thumbnail - CPAN friendly. It needs, however, GD, which means that instead of using Perl Magick for the sole use of generating thumbnails, you'll be using GD for the sole purpose of generating thumbnails... Also, it only has jpeg support currently... But it _is_ easy :-) Issac Jonathan M. Hollin wrote: The WYPUG migration from Win2K to Linux is progressing very nicely. However, despite my best efforts, I can't get Perl Magick to work (Image::Magick compiled successfully and without problems). All I use Perl Magick for is generating thumbnails (which seems like a waste anyway). So, is there an alternative - a module that will take an image (gif/jpeg) and generate a thumbnail from it? I have searched CPAN but haven't noticed anything suitable. If not, is there anyone who would be willing to help me install Perl Magick properly? Kindest regards, Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: mod_perl cookbook ... next steps
[EMAIL PROTECTED] wrote: [snip] As I need information between the stage of life, I would use $r-notes to communicate down the cycle. But then again, if I have some data tied to the session (I use Apache::Session), how can I give it to the PerlHandler. Is $r-notes proofed for any export, object or blessing behavior? I think $r-pnotes should work fine with this... But I'm not positive... Other than that, it sounds fine... Except that usually youll authenticate the user in PerlAuthenHandler and use AuthzHandler to decide whether or not to let him do whatever he's trying to do... The Eagle book had some nice explanations of this... Issac
Re: file globbing question
It occurred to me that using a scheme like this, it might be possible to help improve mod_perl's popularity... Or, at least, the popularity of Toolkits built under mod_perl... Using Files (or the Apache::MIMEMapper module), makes mod_perl a bit more ISP friendly, as it's a lot easier for users to add code to their files... Maybe using Embperl or something like that inside pages... Anyway, it's just a thought... Issac Geoffrey Young wrote: Cees Hek wrote: On Wed, 2002-02-20 at 13:27, John Stauffacher wrote: All, I am a bit confused as to what httpd.conf directives need to be used in order to get apache to execute a PerlHandler when it encounters a certain file type. What I want to do: Execute a handler whenever a *.qw file is accessed. The same handler whether or not the file exists and not look for the file. So the user makes the request: get /somewhere/my.qw and gets the response moo. Then they request /other/place/boo.qw and gets the response moo. I have tried using a Files directive, but it envokes the handler, then looks for the file and throws a 404. Any ideas? The Files directive is the right way to go. Are you sure you are returning OK in your Handler? If you return something else (like DECLINED) then Apache will take over the request and handle it in the default manner (ie look up the file). Returning OK lets Apache know that the request was dealt with appropriately and it can move on to the next phase. another alternative is something like Apache::MIMEMapper... http://www.modperlcookbook.org/download/Apache-MIMEMapper-0.10.tar.gz which expands the AddHandler directive to make it a bit more mod_perl friendly. so, instead of using Files (which is perfectly legitimate) you can instead simply use AddHandler My::Module .qw and Apache will use My::Module::handler() for the content-generation phase. all the stuff Cees said it true, though - you still need to make sure your handler returns OK and follow the other handler rules. HTH --Geoff
Re: another article on perl.com
Can I humbly suggest some articles that would lead to a guide for mod_perl 2? I'm actually a bit embarrassed to admit that this is more out of personal laziness than real need... I've just been so swamped lately, I've never gotten around to looking at the API for Apache 2.0, and therefore have no idea what to expect :-) But it's still a useful thing to have... Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Geoffrey Young [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 5:34 PM Subject: Re: another article on perl.com Geoffrey Young wrote: it seems mod_perl is gathering some serious momentum lately... in addition to Paul's Preventing Cross-site Scripting Attacks article last week http://www.perl.com/pub/a/2002/02/20/css.html we have a new article by Stas, Why mod_perl? http://perl.com/pub/a/2002/02/26/whatismodperl.html so, mod_perl is front and center on perl.com this week. nice work everyone! Yeah, I'm trying to push mod_perl everywhere I can. publicity never hurts. There is a bunch of articles I'm republishing at apacheweek.com. Unfortunately apachetoday.com doesn't publish anymore (but the articles are still available if you search the site) and perlmonth.com has gone ;( At this moment I'm poking Dr.Dobb's J. and a few others. If you know of other prospective magazines looking for articles please let me know. I've about 18 articles in stock and growing. If you want to publish yourself, go ahead help yourself with the guide (reuse/reuse/reuse/...), we need many articles in all possibly relevant publications. Soon I will start working on the new articles for 2.0, but not before the new site is released. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: another article on perl.com
[snip] Just to assure you, 99.9% of the old code will run as is. Though there are many new things ;) Actually, that's what I'm interested in... I've mentioned on the IRC room on a number of occasions, that I'd like to try to use the new threaded interface to try to design some new innovative types of WebApps, based on IPC or shared memory pools... Every once in a while I decide to start looking into it, and then just as quickly put off delving into the Apache 2.0 API... Oh well... It can wait, I suppose :) Issac
Re: Status of mod_perl 2.0
Which gives me another nice idea for articles... How about some pointers in thread safety with Apache/Perl... What you sould and should not do? Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Jeff Stuart [EMAIL PROTECTED] Cc: Mod Perl Devel List [EMAIL PROTECTED]; Mod perl mailing list [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 8:00 PM Subject: Re: Status of mod_perl 2.0 Jeff Stuart wrote: Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all? Tell me what's the status of apache 2.0 and I'll tell you the status of mod_perl 2.0 :) But seriously mod_perl 2.0 will be ready about the time apache 2.0 (i.e. httpd-2.0) gets released. You can start playing with it already. I've successfully run my singlesheaven.com code using mod_perl 2.0 a few months ago. And there are many tests, so you can see what works and what not. Registry is almost completed, a few thread-safety issues unresolved (e.g. chdir() in the threaded env). If you plan on adding a testing platform for you product, make sure to use the Apache::Test framework from 2.0 distro, which rocks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache::GD::Thumbnail-0.03
Changes: Cache control headers are returned to the browser BEFORE the thumbnail is generated now (why I didn't do this originally is beyond me :-)) The uploaded file Apache-GD-Thumbnail-003targz has entered CPAN as file: $CPAN/authors/id/I/IS/ISAAC/Apache-GD-Thumbnail-003targz size: 2589 bytes md5: cecadf3fdfa04f6aa50d94243a49ed0e
Re: problems with $r-status('OK')
You don't want to do that...
You want to do this:
use Apache::Constants qw(:common);
and then $r-status(OK); # (no quotes)
Issac
- Original Message -
From: clayton cottingham [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 04, 2002 6:47 PM
Subject: problems with $r-status('OK')
hello:
im using Apache/1.3.12
and
mod_perl/1.24
every time i use
the $r-status('OK');
it gives me this error
Argument OK isn't numeric in subroutine entry
has anyone come accross this before?
thanks
Re: where is libperl.so.1?
so if it's statically compiled, why are you using LoadModule? Issac J S wrote: Hi there, I've installed an apache build I did onto a Solaris 2.6 box, and when I try to start it I get the following error message: ld.so.1: /opt/apache_1.3.22/bin/httpd: fatal: libperl.so.1: open failed: No such file or directory Killed I can't find libperl.so on either the original box, or the box I'm installing to. Can anyone help me out please? Thanks for any help, JS. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: where is libperl.so.1?
*looks again* oops... I didn't look close enough at tyhe error, assumed it couldn't find mod_perl.so *hits himself in head*. Did you install perl yourself? If so, you may want to make sure that the directory containing the libperl.so file (usually TOP_LEVEL/libexec/) is included in the file /etc/ld.so.conf and then run ldconfig as root. That might help... Issac J S wrote: Not sure I understand your answer. I'm not using LoadModule. JS. so if it's statically compiled, why are you using LoadModule? Issac J S wrote: Hi there, I've installed an apache build I did onto a Solaris 2.6 box, and when I try to start it I get the following error message: ld.so.1: /opt/apache_1.3.22/bin/httpd: fatal: libperl.so.1: open failed: No such file or directory Killed I can't find libperl.so on either the original box, or the box I'm installing to. Can anyone help me out please? Thanks for any help, JS.
Re: checking a site for ssl cert?
Kirk Rogers wrote: hello, kind of a long shot but does anyone know if its possible to check a site for ssl certificate information from a mod perl handler or perl script? thanks k it's all exported into %ENV if you do: SSLOptions + StdEnvVars Issac
Re: [OT] checking a site for ssl cert?
IT's a feature of mod_ssl, not of mod_perl, so the answer is no, it does not need another module to be accessed by standalone perl. Issac Kirk Rogers wrote: What about a standalone CGI script? Is there some module or package I need acquire or is it also exported into %ENV? Thanks, K -Original Message- From: Issac Goldstand [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 7:16 AM To: [EMAIL PROTECTED] Cc: modperl Subject: Re: checking a site for ssl cert? Kirk Rogers wrote: hello, kind of a long shot but does anyone know if its possible to check a site for ssl certificate information from a mod perl handler or perl script? thanks k it's all exported into %ENV if you do: SSLOptions + StdEnvVars Issac
Re: mod_perl does not see multipart POSTs
I'm not sure I understand what you're asking... Apache, on it's own, does not support any internal parsing of POST data, multipart or otherwise, so why should mod_perl? For this, we have the Apache::Request library in mod_perl (Which is the mod_perl interface to the libapreq library for Apache's C API). libapreq supports multipart/form-data, even without a file upload... Issac Vuillemot, Ward W wrote: All, I am still trying to figure out why my setup of mod_perl does not have multipart POSTs. I rebooted my machine, and found that, whereas I reported before mod_perl would try to reload the page (which it should not but send out a text/plain attachment for download), it appears the script (running as a perl handler) does not see any of the multipart POST. Vanilla posts are not a problem, though. Even if the information being sent via multipart is _not_ a file to upload to the server, the information is lost in transit. Here is what is odd. The same scripts/modules unmodified and running as perl_cgi are okay. Multipart forms allow me to upload files, et cetera. In short, I am confident the problem is not with my programming. I am using the code snippet, POST2GET, to capture the one-time read of POST and storing as if it was retrieved via GET. Any ideas how to debug this? I REALLY REALLY would love some feedback. I would love to think that all my effort to stay away from M$ ASP are worth it -- esp. when I stand up to defend Perl, Apache, and mod_perl in an environment that is decidely M$-bent. Thanks! Ward
