RE: CGI::Delete for Apache::Request
At 10:45 PM 5/16/00 -0700, Doug MacEachern wrote: well, form_fields() is descriptive and would fit nicely with the other Apache::Table methods (headers_in, etc)... something like that, i was thinking post_data, but that table also has query string data in it, which might from a get. phooey. Why not compromise and call it form_data. :) will you keep parms() around for folks who already have functions built around it? maybe making a clean break with 2.0? sure, i'll make an alias for it. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: multiple copies of a module
At 11:18 AM 5/17/00 +0300, Stas Bekman wrote: On Wed, 17 May 2000, Gunther Birznieks wrote: I am curious as to why you don't care for 20 different apaches? If you use a mod_proxy front-end, it should be relatively easy to manage 20 different apache's on the backend, especially if you use variables to start them up. There is another command line parameter that can be used to trigger different code in the same conf file (so that they start on different ports for example)... In addition, a solid part of testing mod_perl modules consists of running in single process mode (ala -x parameter)) -- which is invaluable for finding cached code conflicts.. You won't be able to do this if everyone is using the same apache. BTW, this would be a good addition to the guide -- how to manage a mod_perl development environment with more than 1 developer (eg 20 in your case) Both questions are already answered in the guide: Kees' original: http://perl.apache.org/guide/modules.html#Apache_PerlVINC_set_a_differe Gunter's suggestion: http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E :) Excellent! One thing though is that both these suggestions actually tie together to solve a practical problem: Managing Multiple Developers yet are located in two different chapters. I think these sections belong where they do, but perhaps a separate discussion linking these sections (and any other relevant ones) would be useful. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: multiple copies of a module
On Wed, 17 May 2000, Gunther Birznieks wrote: At 11:18 AM 5/17/00 +0300, Stas Bekman wrote: On Wed, 17 May 2000, Gunther Birznieks wrote: I am curious as to why you don't care for 20 different apaches? If you use a mod_proxy front-end, it should be relatively easy to manage 20 different apache's on the backend, especially if you use variables to start them up. There is another command line parameter that can be used to trigger different code in the same conf file (so that they start on different ports for example)... In addition, a solid part of testing mod_perl modules consists of running in single process mode (ala -x parameter)) -- which is invaluable for finding cached code conflicts.. You won't be able to do this if everyone is using the same apache. BTW, this would be a good addition to the guide -- how to manage a mod_perl development environment with more than 1 developer (eg 20 in your case) Both questions are already answered in the guide: Kees' original: http://perl.apache.org/guide/modules.html#Apache_PerlVINC_set_a_differe Gunter's suggestion: http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E :) Excellent! One thing though is that both these suggestions actually tie together to solve a practical problem: Managing Multiple Developers yet are located in two different chapters. I think these sections belong where they do, but perhaps a separate discussion linking these sections (and any other relevant ones) would be useful. These two are disconnected in fact. Since when you develop the code you need just a few processes per developer, you start a separate server for each developer -- and that's what the last link suggests. It shows how to use the front end machine to solve the problem when all the servers are running on the same machine. There is no reason of runing vurtual hosts for each developer, different ports solve this issue much better and simpler. Of course I'd be glad to document other approaches if you will to share. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: multiple copies of a module
Stas Bekman wrote: Both questions are already answered in the guide: Kees' original: http://perl.apache.org/guide/modules.html#Apache_PerlVINC_set_a_differe Gunter's suggestion: http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E Thank you very much this is very helpful (I love the guide, even though it sometimes difficult to find something in it). I think would like to go the Apache::PerlVINC way, as our testing box is very heavily loaded (due to all kinds of non-apache testing going on). I would never get permission to start 20 apache servers. However the URL in the guide: http://perl.apache.org/~dougm/Apache-PerlVINC-0.01.tar.gz does not exist, is there any other place where I can find Apache::PerlVINC? Thanks, Kees
Re: multiple copies of a module
Stas Bekman wrote: Both questions are already answered in the guide: Kees' original: http://perl.apache.org/guide/modules.html#Apache_PerlVINC_set_a_differe Gunter's suggestion: http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E Thank you very much this is very helpful (I love the guide, even though it sometimes difficult to find something in it). Hold on, at this very moment a few mod_perl fellas are working on having a good search engine for the guide. Just give it some more time, I'm trying to bring the best so it'll take a while... I think would like to go the Apache::PerlVINC way, as our testing box is very heavily loaded (due to all kinds of non-apache testing going on). I would never get permission to start 20 apache servers. However the URL in the guide: http://perl.apache.org/~dougm/Apache-PerlVINC-0.01.tar.gz does not exist, is there any other place where I can find Apache::PerlVINC? Indeed, it's not there. Doug? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: Apache::DBI and autocommit
-Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 16, 2000 10:32 PM To: William Deegan Cc: [EMAIL PROTECTED] Subject: Re: Apache::DBI and autocommit On Tue, 16 May 2000, William Deegan wrote: If autocommit is not set and a script exits the transaction will be rolled back. The question I have is when the database handle is re-used will the autocommit still be unset if the script that set it errors out? Yes, Apache::DBI doesn't touch your autocommit settings. true, but Apache::DBI caches connections per connect string, so a database handle called with AutoCommit=0 in one script and AutoCommit=1 in another will result in two cached handles. William - are you creating a $dbh and setting AutoCommit in a seperate step/script? If so, I'm not sure that the new AutoCommit attribute will be a part of the cached database handle, regardless of the exit status of the script. Can anyone confirm this? --Geoff - Perrin
Re: Apache::DBI and autocommit
On Tue, 16 May 2000, William Deegan wrote:
Greetings,
from the various perldocs and web pages I understand the following
to be true.
If autocommit is not set and a script exits the transaction will be
rolled
back.
The question I have is when the database handle is re-used will the
autocommit still be unset if the script that set it errors out?
No. What you need to do is use an exception handler around your code (see
the guide/perl.html) and commit if your code ran OK, or rollback if
not. Here's how I do it (sort of - there's more code to it than this):
eval {
dispatch();
};
if ($@) {
rollback;
output('errorpage.template', $@-value);
return OK;
}
return OK;
However also ensure that your transaction handling is fine grained at the
level its happening. I use DBIx::AnyDBD so that I can do this:
$db-begin_tran;
$db-do_stuff; # calls die() if it fails
# non-db stuff that calls die() if it fails
$db-commit;
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Guide search engine (was Re: multiple copies of a module)
Stas Bekman wrote: Hold on, at this very moment a few mod_perl fellas are working on having a good search engine for the guide. Just give it some more time, I'm trying to bring the best so it'll take a while... I'm glad you brought this up again. Since I mentioned I'd be happy to host such a thing, and asked for suggestions, I've got a total of one (from Stas--thanks!). That suggestion was to use ht://dig http://www.htdig.org/. Has anyone got a search engine up and running that they're happy with? Stas has made the good point that it needs to be able to hilight found words, since the pages are quite large. If anyone has a chance to do a bit of research about (free) search engines, I'd really appreciate it if you could let me know what you find out. It'd be nice publicity if it was mod_perl based, I guess, but it doesn't really matter. My only concern is that it seems a little odd to keep this just to the Guide. Wouldn't it be useful for the rest of perl.apache.org? I wouldn't have thought it's much extra work to add a drop-down box to search specific areas of the sight (the Guide being one)... If there's a good reason to have the Guide's search engine separate to the rest of perl.apache.org, should it have a separate domain (modperlguide.org?, guide.perl.apache.org?)? -- Jeremy Howard [EMAIL PROTECTED]
Re: Guide search engine (was Re: multiple copies of a module)
BTW: Your email client is broken and not wrapping words. On Wed, 17 May 2000, Jeremy Howard wrote: Stas Bekman wrote: Hold on, at this very moment a few mod_perl fellas are working on having a good search engine for the guide. Just give it some more time, I'm trying to bring the best so it'll take a while... I'm glad you brought this up again. Since I mentioned I'd be happy to host such a thing, and asked for suggestions, I've got a total of one (from Stas--thanks!). That suggestion was to use ht://dig http://www.htdig.org/. While htdig is a reasonable engine, Stas's idea is this needs to be "guide specific". Meaning what I'm not sure, but I'm assuming it means to pick out only certain words to index... Has anyone got a search engine up and running that they're happy with? I just wrote a very simple SQL based engine - so I would say I'm happy with that. It's fast and it's all in perl. I could very simply rip out the search parts of the code for someone to play with if they wanted to. Stas has made the good point that it needs to be able to hilight found words, since the pages are quite large. If anyone has a chance to do a bit of research about (free) search engines, I'd really appreciate it if you could let me know what you find out. It'd be nice publicity if it was mod_perl based, I guess, but it doesn't really matter. I think word highlighting is overrated. It's only necessary in this case because the guide is so damn huge now. The size problem could be eliminated by making the guide split itself up into smaller sections. My proposal would be to do that by converting the guide to docbookXML and use AxKit to display the resulting docbook pages. The AxKit docbook stylesheets are nice and friendly, and written in Perl, not some obscure XML stylesheet language. And after all that, it would make converting the guide to a format O'Reilly likes to publish (i.e. docbook), trivial. My only concern is that it seems a little odd to keep this just to the Guide. Wouldn't it be useful for the rest of perl.apache.org? I wouldn't have thought it's much extra work to add a drop-down box to search specific areas of the sight (the Guide being one)... perl.apache.org already has a search engine. If there's a good reason to have the Guide's search engine separate to the rest of perl.apache.org, should it have a separate domain (modperlguide.org?, guide.perl.apache.org?)? guide.modperl.org ? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RFC: Apache::Request::Forms (or something similar)
Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. The module is currently planned to be fairly bare-boned, only adding form element generation methods for methods which will benefit from CGI.pm-style sticky values, and the parameters these methods take are likely to be a lot more restricted than CGI.pm's (not difficult, really). However, this could change in the unlikely event that we get deluged with feature requests. -- Peter Haworth [EMAIL PROTECTED] "We're sorry. The brain you have mailed has been disconnected or is no longer in service. Please re-check the address and send your message again. If you feel you have reached this recording in error, JUST STOP CREATING EVIL PUNCTUATION OPERATORS, SO CHIP'S BRAIN WILL STOP EXPLODING. Thank you." -- Chip Salzenberg
Re: Guide search engine (was Re: multiple copies of a module)
Jeremy Howard wrote: I'm glad you brought this up again. Since I mentioned I'd be happy to host such a thing, and asked for suggestions, I've got a total of one (from Stas--thanks!). That suggestion was to use ht://dig http://www.htdig.org/. Has anyone got a search engine up and running that they're happy with? Stas has made the good point that it needs to be able to hilight found words, since the pages are quite large. If anyone has a chance to do a bit of research about (free) search engines, I'd really appreciate it if you could let me know what you find out. It'd be nice publicity if it was mod_perl based, I guess, but it doesn't really matter. I'm happy with ht://dig, I use it mainly for looking up docs I've squirreled away in /manual. (instead of grep) It's been a while since I've been to htdig.org but I did grab a tarball recently, so I'm fairly confident there isn't* an existing mod_perl wrapper -- but maybe there should be. There are a number of perl scripts in the distribution, and I thought* there was a plain Perl wrapper, but I could be mistaken. I think a mod_perl frontend/wrapper could work well, that is, htsearch is about 900K+ and takes a moment to fire up (on my box anyway) -- how much worse could it be? OTOH, one could* (conceivably) get crazy and access the DB's directly and maybe XS any needed portions of htsearch (ambitious :-). However, this still leaves htdig, htfuzzy, htmerge, etc .. to handle the indexing. As far as highlighting, I have a piece of code I'm using -- we could use it as a starting point. Downside is it uses $` $' (it can probably be tweeked to avoid this), but it handles the critical stuff like skipping keywords within href's/tags, etc. RE: Matt Sergeant -- Perhaps highlighting is overrated, but it usually doesn't hurt. I too have a proprietary search facility, and a inverted indexing prototype (stores packed doc-id integers in MySQL, for example) -- but a great deal of work has gone into ht://dig .. My only concern is that it seems a little odd to keep this just to the Guide. Wouldn't it be useful for the rest of perl.apache.org? I wouldn't have thought it's much extra work to add a drop-down box to search specific areas of the sight (the Guide being one)... I'd have to agree there. If there's a good reason to have the Guide's search engine separate to the rest of perl.apache.org, should it have a separate domain (modperlguide.org?, guide.perl.apache.org?)? -- Jeremy Howard [EMAIL PROTECTED] ht://dig allows for the param 'restrict' = /to_this_directory .. which might be useful for seperating things. Count me in, whatever we choose. -Jay J # use Text::Wrapper;
Setting authentication via a PerlInitHandler?
Hi, all.
I am trying to figure out a way to set a PerlAuthenHandler (using
$r-push_handlers()) from a PerlInitHandler.
Here is what I have so far:
Location /test
PerlInitHandler Test::Init
/Location
package Test::Init;
sub handler {
my $r = shift;
#
# First try: gave me errors, so I swicthed to the method below
# "[error]Usage: Apache::auth_type(r) at /apache/lib/Test/Init.pm line 30."
#$r-auth_type('Basic');
#$r-auth_name('Test');
#$r-requires([{requirement = 'valid-user',method_mask = -1}]);
# These give me no errors in the error log
Apache::auth_type('Basic');
Apache::auth_name('BGEP')
Apache::requires([{requirement = 'valid-user',method_mask = -1}]);
$r-push_handlers(PerlAuthenHandler = \auth);
return OK;
}
...and I get nothing useful. auth is not being called (it returns OK and
prints to STDERR).
Setting the AuthName, AuthType, and requires in the httpd.conf, with a
PerlAuthenHandler of Test::Init::auth, works just fine, so the problem
seems to be with the setting of these through handler.
My setup is Apache 1.3.12, mod_perl 1.23, Perl 5.6.0 (all built from source,
with mod_perl compiled staticly) on Linux 2.2.14.
Any ideas?
darren
--
UNIX is a process that runs under Emacs.
Re: Apache::Sandiwch and cookies?
"JS" == Jim Serio [EMAIL PROTECTED] writes:
JS wrapper script and it works fine so I'm inclined to
JS think thatSandwich emits a header before even processing
JS the header file.
Yes it does. A quick scan of the Apache::Sandwich::handler() function
would confirm this:
#send headers to the client
$r-content_type("text/html");
$r-send_http_header;
return OK if $r-header_only(); # HEAD request, so skip out early!
#run subrequests to include the HEADER uri's
foreach (@header) {
my $status = Apache::Include-virtual($_, $r) if $_;
warn "sandwiching $_ ($status)\n" if $Debug;
#bail if we fail!
return $status unless $status == DOCUMENT_FOLLOWS;
}
# run subrequest using the specified handler (or default handler)
# for the main document.
etc.
I has to send the headers before it sends the header parts, and it has
to send the header parts before it sends the requested document.
You can mimic this using the Apache::Sandwich::insert_parts() function
something like this instead of sandwiching your perl program directly.
#! /usr/local/bin/perl
use strict;
# program template
use CGI;
use Apache::Sandwich;
use vars qw($query);
$query = new CGI or die "Something failed";
print $query-header();
Apache::Sandwich::insert_parts('HEADER');
# program stuff goes here.
Apache::Sandwich::insert_parts('FOOTER');
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. -dave /*== www.urth.org We await the New Sun ==*/
why a mod_perl module,Footer.pm stop cgi-bin?
Hello! All,
I am new user on mod_perl, and study it from the book, "Write Apache Modules with
Perl and C". I installed a Handler, Footer.pm, in apache by embeding the following
lines in the file apache.conf:
Alias / /usr/local/share/apache/htdocs/
Location /
SetHandlerperl-script
PerlHandler Apache::Footer
/Location
It works but the scripts in /cgi-bin/ do not function at all! If I comment this
handler
, the cgi-bin works again. I don't know whay? Can somebody tell me the reason and how
to overcome this side effect? The code and the system information is appended with
this
email as follow.
Many Thanks!
Sam Xie
Operating System: FreeBSD-4.0 Current
Perl Version: Perl 5.005_03
Apache Version:Apache13-php4
Mod_perl version: mod_perl-1.22
Perl Handler: Footer.pm
-Code -
package Apache::Footer;
use strict;
use Apache::Constants qw(:common);
use Apache::File ();
sub handler {
my $r = shift;
return DECLINED unless $r-content_type() eq 'text/html';
my $file = $r-filename;
unless (-e $r-finfo) {
$r-log_error("File does not exist: $file");
return NOT_FOUND;
}
unless (-r _) {
$r-log_error("File permissions deny access: $file");
return FORBIDDEN;
}
my $modtime = localtime((stat _)[9]);
my $fh;
unless ($fh = Apache::File-new($file)) {
$r-log_error("Couldn't open $file for reading: $!");
return SERVER_ERROR;
}
my $footer = END;
hr
copy; 2000 a href="http://samxie.cl.msu.edu"Sam Xie's Footer; /abr
emLast Modified: $modtime/em
END
$r-send_http_header;
while ($fh) {
s!(/body)!$footer$1!oi;
} continue {
$r-print($_);
}
return OK;
}
1;
__END__
Re: RFC: Apache::Request::Forms (or something similar)
If you are considering writing subclasses that do similar things to CGI.pm, you might consider looking at CGI.pm 3.0 as the various features (eg HTML generation) are more broken out... And then the two would run more parallel to each other. At 03:30 PM 5/17/00 +0100, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. The module is currently planned to be fairly bare-boned, only adding form element generation methods for methods which will benefit from CGI.pm-style sticky values, and the parameters these methods take are likely to be a lot more restricted than CGI.pm's (not difficult, really). However, this could change in the unlikely event that we get deluged with feature requests. -- Peter Haworth [EMAIL PROTECTED] "We're sorry. The brain you have mailed has been disconnected or is no longer in service. Please re-check the address and send your message again. If you feel you have reached this recording in error, JUST STOP CREATING EVIL PUNCTUATION OPERATORS, SO CHIP'S BRAIN WILL STOP EXPLODING. Thank you." -- Chip Salzenberg
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. Without looking at the new CGI.pm, I'd say that the benefit of our new module would be that it's targetted specifically at mod_perl, so it should hopefully be smaller, and ideally it would be faster. The non-backwards compatible nature of the new interface also allows us to cut down on some of the overhead of CGI.pm's need to figure out which calling style is used. -- Peter Haworth [EMAIL PROTECTED] "Who needs horror movies when we have Microsoft"? -- Christine Comaford, PC Week, 27/9/95
Re: Guide search engine (was Re: multiple copies of a module)
Jeremy Howard wrote: I'm glad you brought this up again. Since I mentioned I'd be happy to host such a thing, and asked for suggestions, I've got a total of one (from Stas--thanks!). That suggestion was to use ht://dig http://www.htdig.org/. Has anyone got a search engine up and running that they're happy with? Stas has made the good point that it needs to be able to hilight found words, since the pages are quite large. If anyone has a chance to do a bit of research about (free) search engines, I'd really appreciate it if you could let me know what you find out. It'd be nice publicity if it was mod_perl based, I guess, but it doesn't really matter. I know this is absolute anathema, considering you guys are developers, but... Have you looked at www.atomz.com, at least as a temporary solution? (A free service for sites with fewer than 500 pages). Basically, the search brings up their page, but you can customize it to look just like one of yours. It truly is fast (as hell) and flexible, and it does highlight found words. Even does soundalikes in the absence of other matches. The result page will show their logo, though, but it's rather unobtrusive. (The biggest drawback, as a long-term solution, is that if you change the look of your pages, you have one more maintenance chore to do, in that you have to go over to atomz.com and change your result page there as well). O'Reilly uses it, if that helps! :-) Try this: http://search.atomz.com/search/?sp-a=0002078e-spsp-q=cgisp-k=Books (Looks for O'Reilly books pages containing 'cgi'). Yeah, I know, I'd rather roll my own, too, given time...
Re: RFC: Apache::Request::Forms (or something similar)
"PH" == Peter Haworth [EMAIL PROTECTED] writes: PH Drew Taylor and I are about to write a subclass of Apache::Request PH which includes form element generation methods, a la CGI.pm. The PH current favourite name is Apache::Request::Forms, but we'd like to PH know if anyone has a better one. Have you looked at CGI::Form that already exists? It would be a good basis. Currently, it is based on CGI::Request but should be able to use Apache::Request one would expect. I think the name CGI::Form is appropriate, since the forms are part of the CGI protocol, not anything mod_perl or Apache sepecific. CGI::Form seems to be an abandoned module, so I'm sure you can get permission to adopt it and extend it. That's my personal recommendation. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. Well, my question is 1). when is it going to be released and 2) what is the interface? Our aim is to produce a much smaller module, intended to be used only under mod_perl, with a much more restricted set of methods. If anyone is interested, here are the form elements we're currently looking at inplementing: textfield() textarea() passwordfield() checkbox() checkbox_group() radio_group() popup_menu() scrolling_list() Our reasoning behind this is very simple. We need (and in fact I rely HEAVILYon ) a few of the HTML generation features in CGI.pm, namely popup_menu for myself. I would like to convert my sites to pure perl handlers, and drop CGI.pm all together. But I can't do this until I have a drop-in replacement, hence this project. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
Vivek Khera wrote: Have you looked at CGI::Form that already exists? It would be a good basis. Currently, it is based on CGI::Request but should be able to use Apache::Request one would expect. Actually, I have briefly looked at this module and looked no more when I realized it was no longer being maintained. I'll take a look at the code and see if it's workable to our goals. It would be really nice to have a starting point, no matter how rough. I had also considered looking at CGI.pm and seeing how it does things internally. Is it "moral" to use code from one module in another if they are both released under the same license? I think the name CGI::Form is appropriate, since the forms are part of the CGI protocol, not anything mod_perl or Apache sepecific. CGI::Form seems to be an abandoned module, so I'm sure you can get permission to adopt it and extend it. Well, in our case we are looking to make it mod_perl specific. See my previous post for my reasoning why. The name is not terribly important to me, but the Apache:: namespace seemed appropriate for it's mod_perl specificness (is that a word?). -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: peter: i question why you want to subclass Apache::Request, rather than provide a helper class that maybe maintains a reference to an Apache::Request object, or some other weaker type of relationship. That is an interesting point Brian. What I would like is a single object I can use to get form params OR generate HTML, ala CGI.pm, but mod_perl specific for speed reasons. The idea is to have as small a memory footprint as possible, using the mod_perl API only. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Segfault on DBI-connect
Many of us have been experiencing segfaults on DBI-connect when using the
DBD-mysql
drivers.
I wonder if anyone has found a solution.
I've appended a pretty comprehensive overview of the problem below.
Problem description: Child Apache process segfaults on DBI-connect with
Apache
1.3.12 and Msql-Mysql-modules-1.22{11,12,13,14} (maybe other versions,
too). This
happens with mod_perl versions 1.22 through 1.24. I happen to be running
RedHat
6.1 with egcs-2.91.66, but I've built everything (from Perl to Apache) from
scratch.
Anyway, the point of failure has been found: the MySQL mysql_real_connect()
routine called by Msql-Mysql-modules-1.22{11-14} gets passed a NULL first
arg.
So far nobody has figured out what is going on here, and why this problem
has only now started to crop up. It seemed to appear when I upgraded
mod_perl
to 1.22 and Apache to 1.3.12.
Here's one of my low-level traces. Farther below I offer a DBI-trace(9)
trace,
which shows what's going on from Perl/DBI/DBD's point of view.
Running Apache with a -X argument yields the following backtrace when my
mod_perl module does a DBI-connect (str, username, passwd, { options }).
Note the null mysql argument
|
v
#0 0x80ef5b7 in mysql_real_connect (mysql=0x0,
host=0x8a99db8 "catlin.cis.brown.edu", user=0x8a9b550 "proxystuff",
passwd=0x8a9b568 "Kui0-,12!", db=0x8a99e40 "proxysession", port=3306,
unix_socket=0x0, client_flag=0) at libmysql.c:1125
#1 0x402d01fd in mysql_dr_connect ()
from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#2 0x402d0540 in _MyLogin ()
from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
I really don't know how the null first argument is getting passed to
mysql_real_connect.
Here's a DBI-trace (9) of what's going on. I confess that I don't
understand
most of this output (which comes from my Apache error log file):
DBI 1.13-nothread dispatch trace level set to 9
-
DBI-Apache::DBI::connect(dbi:mysql:database=proxysession;host=catlin.cis.brown.edu;port=3306,
proxystuff, Kui0-,12!)
- DBI-install_driver(mysql) for perl=5.00503 pid=14122 ruid=99 euid=99
install_driver: DBD::mysql loaded (version 2.0414)
New DBI::dr (for DBD::mysql::dr, parent=, id=)
dbih_setup_handle(DBI::dr=HASH(0x858a0e8)=DBI::dr=HASH(0x8930414),
DBD::mysql::dr, 0, Null!)
dbih_make_com(Null!, DBD::mysql::dr, 84)
dbih_setup_attrib(DBI::dr=HASH(0x8930414), Err, Null!) SCALAR(0x89259cc) (already
defined)
dbih_setup_attrib(DBI::dr=HASH(0x8930414), State, Null!) SCALAR(0x858a3ac)
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8930414), Errstr, Null!) SCALAR(0x89259e4)
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8930414), Handlers, Null!) ARRAY(0x89304c8)
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x8930414), Debug, Null!) 0 (already defined)-
install_driver= DBI::dr=HASH(0x858a0e8)
FETCH DISPATCH (DBI::dr=HASH(0x8930414) rc2/1 @2 g0 a866b270) at
/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
- FETCH= 'mysql' ('Name' from cache) at
/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
connect DISPATCH (DBI::dr=HASH(0x858a0e8) rc1/5 @5 g0 a866b288) at
/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 120.
- connect for DBD::mysql::dr (DBI::dr=HASH(0x858a0e8)~0x8930414
'database=proxysession;host=catlin.cis.brown.edu;port=3306' 'proxystuff' 'pKui0-,12!'
HASH(0x892441c))
New DBI::db (for DBD::mysql::db, parent=DBI::dr=HASH(0x8930414),
id=HASH(0x8930450))
dbih_setup_handle(DBI::db=HASH(0x89304a4)=DBI::db=HASH(0x893a058),
DBD::mysql::db, 8587d60, HASH(0x8930450))
dbih_make_com(DBI::dr=HASH(0x8930414), DBD::mysql::db, 520)
dbih_setup_attrib(DBI::db=HASH(0x893a058), Err, DBI::dr=HASH(0x8930414))
SCALAR(0x89259cc) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x893a058), State, DBI::dr=HASH(0x8930414))
SCALAR(0x858a3ac) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x893a058), Errstr, DBI::dr=HASH(0x8930414))
SCALAR(0x89259e4) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x893a058), Handlers, DBI::dr=HASH(0x8930414))
ARRAY(0x89304c8) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x893a058), Debug, DBI::dr=HASH(0x8930414)) 0
(already defined)
imp_dbh-connect: dsn = database=proxysession;host=catlin.cis.brown.edu;port=3306,
uid = proxystuff, pwd = Kui0-,12!
imp_dbh-MyLogin: dbname = proxysession, uid = proxystuff, pwd = Kui0-,12!,host =
catlin.cis.brown.edu, port = 3306
imp_dbh-MyConnect: host = catlin.cis.brown.edu, port = 3306, uid = proxystuff,
pwd = Kui0-,12!
imp_dbh-MyConnect: client_flags = 0
[Wed May 17 11:17:29 2000] [notice] child pid 14122 exit signal Segmentation fault
(11)
--
Richard Goerwitz[EMAIL PROTECTED]
Re: Setting authentication via a PerlInitHandler?
I am trying to figure out a way to set a PerlAuthenHandler (using
$r-push_handlers()) from a PerlInitHandler.
Follo-wup with more info.
here is my auth sub:
sub auth {
my $r = shift;
print STDERR Data::Dumper-Dump( [$r], ['Apache']);
print STDERR "in auth handler\n"
return OK;
}
Adding this to the handler sub:
print STDERR "Before pushing:";
$do-get_handlers;
$r-push_handlers(PerlAuthenHandler = \bgep_auth );
print STDERR "After pushing:";
$do-get_handlers;
give me this in the error_log:
Before pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
After pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
CODE(0x831a06c) = enabled as PerlAuthenHandler
Apparently, pushing a code ref onto the handler stack, which is what the docs
say to do, isn't what I want. Changing the relevent section in handler to:
print STDERR "Before pushing:";
$do-get_handlers;
$r-push_handlers(PerlAuthenHandler = bgep_auth );
print STDERR "After pushing:";
$do-get_handlers;
Gives me:
Before pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
$Apache = undef;
in auth handler
After pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
(It runs the sub in place, and $r is not defined)
darren
--
There is no hell. There is only France.
Re: RFC: Apache::Request::Forms (or something similar)
"bm" == brian moseley [EMAIL PROTECTED] writes: bm actually forms are specified in HTML, not CGI. Ok... if you say so. bm consider writing your forms library to depend on an bm interface, not a specific class, so that users can provide bm either a CGI object or an Apache::Request object. perhaps bm the only interface you need is $obj-param? This would make a great case for using CGI::Form then... That seems to be the only thing it relies on from my quick glance at the code.
Re: RFC: Apache::Request::Forms (or something similar)
"DT" == Drew Taylor [EMAIL PROTECTED] writes: I think the name CGI::Form is appropriate, since the forms are part of DT Well, in our case we are looking to make it mod_perl specific. See my Right... But if your interface only relies on calling $x-param() then it can be based on any CGI-ish module that provides that interface. I think this will be a big win. I can't imagine any other interface you'd need to create this module, and that's only for the stickyness of it. As for borrowing code, go for it, but be sure to attribute it in both the code and the documentation. Most modules are distributed under the Perl license, which is quite liberal. I'd suggest making the calling convention require named parameters and require it to be an object rather than a function call interface.
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Drew Taylor wrote: That is an interesting point Brian. What I would like is a single object I can use to get form params OR generate HTML, ala CGI.pm, but mod_perl specific for speed reasons. The idea is to have as small a memory footprint as possible, using the mod_perl API only. what part of the mod_perl api are you going to actually use? with the list of widgets you sent earlier, i'm hard pressed to see where anything other than $obj-param will be useful to you. i don't see where you would get any benefit from being "mod_perl specific".
Re: RFC: Apache::Request::Forms (or something similar)
At 11:32 AM 5/17/00 -0400, Drew Taylor wrote: Vivek Khera wrote: Have you looked at CGI::Form that already exists? It would be a good basis. Currently, it is based on CGI::Request but should be able to use Apache::Request one would expect. Actually, I have briefly looked at this module and looked no more when I realized it was no longer being maintained. I'll take a look at the code and see if it's workable to our goals. It would be really nice to have a starting point, no matter how rough. I had also considered looking at CGI.pm and seeing how it does things internally. Is it "moral" to use code from one module in another if they are both released under the same license? "moral" or "legal". In my book it is moral to take code snippets as long as due credit is given for Open Source. At the level of code snippets, that's really how we all learn programming anyway. I would be hard pressed to find anyone that writes truly original code (unless they make it look really weird like the obfuscation contests!). That is usually what the Open Source licenses request anyway. If people didn't want you to pervert the code, they wouldn't have made it open source. I think the name CGI::Form is appropriate, since the forms are part of the CGI protocol, not anything mod_perl or Apache sepecific. CGI::Form seems to be an abandoned module, so I'm sure you can get permission to adopt it and extend it. Well, in our case we are looking to make it mod_perl specific. See my previous post for my reasoning why. The name is not terribly important to me, but the Apache:: namespace seemed appropriate for it's mod_perl specificness (is that a word?). You stated why but it seemed a bit vague. You mention performance. What about CGI.pm's HTML generation methods is too slow that you will improve using mod_perl specific features? And why is the API itself a reason for it being slow that you have to make the API itself different from CGI.pm?
Re: RFC: Apache::Request::Forms (or something similar)
At 11:25 AM 5/17/00 -0400, you wrote: Autarch wrote: On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. Well, my question is 1). when is it going to be released and 2) what is the interface? Our aim is to produce a much smaller module, intended to be used only under mod_perl, with a much more restricted set of methods. If anyone is interested, here are the form elements we're currently looking at inplementing: 1) It will be released when there are enough people banging on it and submitting comments. Hence it is in alpha because the API could change in the future, BUT it is wanting for people to help test. 2) The interface for CGI.pm 3.x is that the monolithic pre-3.0 CGI.pm was broken into a well defined object hierarchy. Otherwise, I believe it is basically the same API.
Re: Guide search engine (was Re: multiple copies of a module)
BTW: Your email client is broken and not wrapping words. I know--sorry. I'm fixing that this week. I'm just going through the RFCs to see exactly how to implement this right... (The email client is a web-based thing I've written in mod_perl--of course ;-) I just wrote a very simple SQL based engine - so I would say I'm happy with that. It's fast and it's all in perl. I could very simply rip out the search parts of the code for someone to play with if they wanted to. Sounds good. Personally, I'd rather a simple engine we can fiddle with ourselves than a big system written in C. Does your engine generate a database from flat files? Is there some basic parameterisation (a 'stop list' for common words, definable 'keyword' characters, ...)? I think word highlighting is overrated. It's only necessary in this case because the guide is so damn huge now. The size problem could be eliminated by making the guide split itself up into smaller sections. My proposal would be to do that by converting the guide to docbookXML and use AxKit to display the resulting docbook pages. The AxKit docbook stylesheets are nice and friendly, and written in Perl, not some obscure XML stylesheet language. And after all that, it would make converting the guide to a format O'Reilly likes to publish (i.e. docbook), trivial. Your word highlighting statement is, I suspect, controversial. On the other hand, converting to docbook is unlikely to meet much resistance from users--as long as Stas doesn't mind maintaining it!... To get the best of both worlds, why not simply chain the search engine result through a filter that does the highlighting. I bet someone's written such a filter already--anyone? My only concern is that it seems a little odd to keep this just to the Guide. Wouldn't it be useful for the rest of perl.apache.org? I wouldn't have thought it's much extra work to add a drop-down box to search specific areas of the sight (the Guide being one)... perl.apache.org already has a search engine. So I've heard, but: * Where is it? (doing a Find on the front page doesn't show it) * Does it do highlighting? * Can you select a subset of the site? (e.g. just the Guide) If there's a good reason to have the Guide's search engine separate to the rest of perl.apache.org, should it have a separate domain (modperlguide.org?, guide.perl.apache.org?)? guide.modperl.org ? Looks like modperl.org is taken: Domain Name: MODPERL.ORG Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: www.networksolutions.com Name Server: DNS2.BASCOM.COM Name Server: DNS.THAKKAR.NET Updated Date: 24-nov-1999 They're not using it though--maybe they would transfer? Probably better to stick in the perl.apache.org domain though. BTW, thanks to everyone who's already responded privately to my renewed request. Keep it up! -- Jeremy Howard [EMAIL PROTECTED]
Re: Guide search engine (was Re: multiple copies of a module)
On Wed, 17 May 2000, Jeremy Howard wrote: I just wrote a very simple SQL based engine - so I would say I'm happy with that. It's fast and it's all in perl. I could very simply rip out the search parts of the code for someone to play with if they wanted to. Sounds good. Personally, I'd rather a simple engine we can fiddle with ourselves than a big system written in C. Does your engine generate a database from flat files? Is there some basic parameterisation (a 'stop list' for common words, definable 'keyword' characters, ...)? Well it's just perl, so there's a separate word tokenizer, a separate db inserter and a separate searcher (which is split into query parser and SQL builder). The db inserter is aware of "ignore words" which are stored in the DB. I think word highlighting is overrated. It's only necessary in this case because the guide is so damn huge now. The size problem could be eliminated by making the guide split itself up into smaller sections. My proposal would be to do that by converting the guide to docbookXML and use AxKit to display the resulting docbook pages. The AxKit docbook stylesheets are nice and friendly, and written in Perl, not some obscure XML stylesheet language. And after all that, it would make converting the guide to a format O'Reilly likes to publish (i.e. docbook), trivial. Your word highlighting statement is, I suspect, controversial. On the other hand, converting to docbook is unlikely to meet much resistance from users--as long as Stas doesn't mind maintaining it!... To get the best of both worlds, why not simply chain the search engine result through a filter that does the highlighting. I bet someone's written such a filter already--anyone? My only concern is that it seems a little odd to keep this just to the Guide. Wouldn't it be useful for the rest of perl.apache.org? I wouldn't have thought it's much extra work to add a drop-down box to search specific areas of the sight (the Guide being one)... perl.apache.org already has a search engine. So I've heard, but: * Where is it? (doing a Find on the front page doesn't show it) At the bottom of all guide pages. * Does it do highlighting? No. * Can you select a subset of the site? (e.g. just the Guide) No. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Guide search engine (was Re: multiple copies of a module)
At 11:19 17/05/2000 -0500, Jeremy Howard wrote: Your word highlighting statement is, I suspect, controversial. On the other hand, converting to docbook is unlikely to meet much resistance from users--as long as Stas doesn't mind maintaining it!... To get the best of both worlds, why not simply chain the search engine result through a filter that does the highlighting. I bet someone's written such a filter already--anyone? I haven't played with it, but getting docbook out of the guide should be as easy as using Pod::DocBook. Fwiw, there's also been some work done on coming up with an xpod dtd, but I don't know how far it's advanced. .Robin To err is human, to purr feline.
Re: Guide search engine (was Re: multiple copies of a module)
On Wed, 17 May 2000, Robin Berjon wrote: At 11:19 17/05/2000 -0500, Jeremy Howard wrote: Your word highlighting statement is, I suspect, controversial. On the other hand, converting to docbook is unlikely to meet much resistance from users--as long as Stas doesn't mind maintaining it!... To get the best of both worlds, why not simply chain the search engine result through a filter that does the highlighting. I bet someone's written such a filter already--anyone? I haven't played with it, but getting docbook out of the guide should be as easy as using Pod::DocBook. Fwiw, there's also been some work done on coming up with an xpod dtd, but I don't know how far it's advanced. I've played with Pod::DocBook, and it's a good start, but uses the DocBook SGML DTD, so you can't process it with XML tools. It also doesn't support =over =item =back, which is a pretty major limitation, IMHO. However patching it to support that shouldn't be too hard. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Guide search engine (was Re: multiple copies of a module)
I know I'm late to this party, but I thought I'd point out a couple of options: - The Search::InvertedIndex module on CPAN (uses dbm files, I think). - The DBIx::TextIndex module on CPAN (uses MySQL). - The WAIT module on CPAN (uses dbm files). - Glimpse: http://webglimpse.org/. - Swish++: http://www.best.com/~pjl/software/swish/ (no, it's not the same one apache.org is using). I've also had great success with htdig. Maybe I'll try spidering the guide with and see how it does. - Perrin
Re: Guide search engine (was Re: multiple copies of a module)
...the perl.apache.org search facility * Where is it? (doing a Find on the front page doesn't show it) At the bottom of all guide pages. How funny--I'd never even noticed it! I see that it's using 'Swish-E' http://sunsite.berkeley.edu/SWISH-E/. Stas--did you get that up and running? Can we tailor it for our needs? Here's an attempt at listing what I think we've decided we should aim for: - Allow restriction of search to just the guide - Allow searching of other documents through a popup selection (probably make the guide the default?) - Highlight found words - Try and index in a way that suits programmers, not English writers. e.g. include @, %, $, ::, in indexed words. Have I missed anything? (I'm ignoring the docbook issue for the moment since it's not directly related, and I guess it's really Stas' call anyhow.) I would have thought the best bet would be to put it on the footer of every perl.apache.org page. A popup which allows selecting a subset of the site might default to either 'whole site' or 'mod_perl Guide', or maybe it changes it's default to whatever part of the site is currently being viewed... The outstanding issues, I believe, are: - Who looks after the perl.apache.org search facility? Are they happy to expand its functionality as described? - What tool? Potential options so far are Swish-e, htdig, or custom Perl (perhaps based on Matt's engine). Any of these could be piped through a word-hilighting filter - What's the best 1st step? i.e. How can we get a simple search going quickly, while providing the foundation for a more complete system down the track? - Who's going to do the actual work? As I've mentioned, if a machine is required, I'm happy to provide it. However, I don't have the experience in this area to lead the work--although of course I'll contribute where I can! It would be nice to get a private mailing list going to avoid filling up this list too much more. Anyone who's interesting in getting involved, email me, and I'll ensure that I add your name to the list. You don't have to be a programming guru, of course... there's always plenty of ways to get involved in these things. -- Jeremy Howard [EMAIL PROTECTED]
Re: RFC: Apache::Request::Forms (or something similar)
Gunther Birznieks wrote: You stated why but it seemed a bit vague. You mention performance. What about CGI.pm's HTML generation methods is too slow that you will improve using mod_perl specific features? And why is the API itself a reason for it being slow that you have to make the API itself different from CGI.pm? It's not CGI.pm's API that I want to change, I just want to make it leaner. It sounds like version 3 would accomplish this, so perhaps this is all a waste of everyone's time. Let me restate, I have no problem with CGI's HTML generation methods. I would just like something smaller, as far as memory usage goes. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: what part of the mod_perl api are you going to actually use? with the list of widgets you sent earlier, i'm hard pressed to see where anything other than $obj-param will be useful to you. i don't see where you would get any benefit from being "mod_perl specific". See my reply to Gunther. Basically, I want a leaner (less memory usage) module to use for HTML generation. I guess I was wrong to say that using "mod_perl specific" API calls would make it faster. Perhaps one could say it's "faster" based on the fact that it will use Apache::Request (written in C as we all know), and it is my understanding that Apache::Request is faster that CGI.pm. It sounds like this might all be moot anyway once CGI.pm v 3 is released. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: Setting authentication via a PerlInitHandler?
you definitely do want to pass the coderef to push_handlers...
ok, maybe I get what's going on...
PerlAuthenHandler will only be called if AuthName, AuthType, and require
directives are set in httpd.conf (or at least, so I gather from the docs).
also from the docs, all three of those directives seem to be read-only. So,
and I'm only guessing here, it would seem that you can't force
PerlAuthenHandlers to run if the directory (or file) isn't already set up
for authentication.
running a few quick tests, the Authen phase isn't even entered, even when
push_handlers() is used...
maybe you'd be better off pushing an Access handler? Or setting up
everything for Authen?
HTH
--Geoff
-Original Message-
From: darren chamberlain [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 17, 2000 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Setting authentication via a PerlInitHandler?
I am trying to figure out a way to set a PerlAuthenHandler (using
$r-push_handlers()) from a PerlInitHandler.
Follo-wup with more info.
here is my auth sub:
sub auth {
my $r = shift;
print STDERR Data::Dumper-Dump( [$r], ['Apache']);
print STDERR "in auth handler\n"
return OK;
}
Adding this to the handler sub:
print STDERR "Before pushing:";
$do-get_handlers;
$r-push_handlers(PerlAuthenHandler = \bgep_auth );
print STDERR "After pushing:";
$do-get_handlers;
give me this in the error_log:
Before pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
After pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
CODE(0x831a06c) = enabled as PerlAuthenHandler
Apparently, pushing a code ref onto the handler stack, which
is what the docs
say to do, isn't what I want. Changing the relevent section
in handler to:
print STDERR "Before pushing:";
$do-get_handlers;
$r-push_handlers(PerlAuthenHandler = bgep_auth );
print STDERR "After pushing:";
$do-get_handlers;
Gives me:
Before pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
$Apache = undef;
in auth handler
After pushing:
Debug get_handlers for [127.0.0.7] /test/ during PerlInitHandler
(It runs the sub in place, and $r is not defined)
darren
--
There is no hell. There is only France.
passing Apache::File to XS code that expects FILE *?
Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? There's too much perl magic going on in the Apache::File implementation for me to see where I can just pull the FILE * out. (Its not strictly necessary that I do this, of course, it would just be nice so I can use Apache::File-tmpfile(). Of course I can do the same basic thing with POSIX::tmpnam().) Jim
Q: DBMS update framework for use within Apache::DBI?
Ciao! I am searching for the makings of a framework built around or within mod_perl/Apache::DBI that supports the consistent update of a record within a database. Primarily I am wanting to ensure read/write integrity between database accesses by the web client, meaning I wish to ensure the record about to be updated meets the following criteria: 1) It exists. If it does not, perform an insert instead 2) If it exists, check that it is unchanged from the time the web client first retrieved it for update. If it has changed, throw an exception. I do not want a "last update wins" situation. This is being done in an mod_perl/embperl/Apache::DBI environment. Suggestions or pointers to additional information would be greatly appreciated. Peace.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? There's too much perl magic going on in the Apache::File implementation for me to see where I can just pull the FILE * out. (Its not strictly necessary that I do this, of course, it would just be nice so I can use Apache::File-tmpfile(). Of course I can do the same basic thing with POSIX::tmpnam().) Or IO::File-new_tmpfile(); -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
getting the hostname from a TransHandler
Hi,
I need to get the "Host:" header sent by the client, from a
TransHandler. Should I be using $r-header_in("Host"), or should I turn
UseCanonicalName off and then use $r-get_server_name?
I'd rather do the first, and it works when I try it, but I'm also
thinking that PerlTransHandlers run before full header parsing, so
$r-header_in might not be recommended at that point... any clues?
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
Re: passing Apache::File to XS code that expects FILE *?
On May 17, Matt Sergeant wrote: Or IO::File-new_tmpfile(); I'd rather not go there. http://marc.theaimsgroup.com/?l=apache-modperlm=95454378223412w=2 Jim
RE: getting the hostname from a TransHandler
-Original Message-
From: Roger Espel Llima [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 17, 2000 2:52 PM
To: [EMAIL PROTECTED]
Subject: getting the hostname from a TransHandler
Hi,
I need to get the "Host:" header sent by the client, from a
TransHandler. Should I be using $r-header_in("Host"), or
should I turn
UseCanonicalName off and then use $r-get_server_name?
I'd rather do the first, and it works when I try it, but I'm also
thinking that PerlTransHandlers run before full header parsing,
I don't think so - request-header parsing happens prior to the
PostReadRequest phase.
all headers_in are available to you by uri translation.
HTH
--Geoff
so
$r-header_in might not be recommended at that point... any clues?
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: On May 17, Matt Sergeant wrote: Or IO::File-new_tmpfile(); I'd rather not go there. http://marc.theaimsgroup.com/?l=apache-modperlm=95454378223412w=2 Well, this may be true, but if you load IO::File before startup then it's not too big a deal... Alternatively use File::Temp on CPAN, Apache-gensym(), and open()/sysopen(). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: getting the hostname from a TransHandler
On Wed, May 17, 2000 at 03:15:01PM -0400, Geoffrey Young wrote: I don't think so - request-header parsing happens prior to the PostReadRequest phase. all headers_in are available to you by uri translation. hmm.. the eagle book seems to say the opposite. anyway, it works :) -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
RE: getting the hostname from a TransHandler
This works for me and I use it widely:
UseCanonicalName off
and my $server = $r-header_in('Host');
-
Best regards,
Karyn Ulriksen
Chief Systems Architect
PublicHost
22 Mauchly, Suite 200
Irvine, California 92618 USA
Phone: (949) 743-2000
email: [EMAIL PROTECTED]
URL: http://www.publichost.com
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 17, 2000 12:15 PM
To: 'Roger Espel Llima'; [EMAIL PROTECTED]
Subject: RE: getting the hostname from a TransHandler
-Original Message-
From: Roger Espel Llima [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 17, 2000 2:52 PM
To: [EMAIL PROTECTED]
Subject: getting the hostname from a TransHandler
Hi,
I need to get the "Host:" header sent by the client, from a
TransHandler. Should I be using $r-header_in("Host"), or
should I turn
UseCanonicalName off and then use $r-get_server_name?
I'd rather do the first, and it works when I try it, but I'm also
thinking that PerlTransHandlers run before full header parsing,
I don't think so - request-header parsing happens prior to the
PostReadRequest phase.
all headers_in are available to you by uri translation.
HTH
--Geoff
so
$r-header_in might not be recommended at that point... any clues?
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
Upload file without file-selection field
Is there a way I can upload files from client machines to server without using the browse button (file-selection field) ? Basically what I need is to set file names in the script somewhere(?) before users click on submit button. Sorry I'm new to both mod_perl and Apache, I don't know what I want is possible or not with Apache:Request. I did install the Apache::Request module (libapreq) and run through the perl sample ok but it needs user to select file before upload. Thanks James
RE: getting the hostname from a TransHandler
-Original Message- From: Roger Espel Llima [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 17, 2000 3:22 PM To: Geoffrey Young Cc: [EMAIL PROTECTED] Subject: Re: getting the hostname from a TransHandler On Wed, May 17, 2000 at 03:15:01PM -0400, Geoffrey Young wrote: I don't think so - request-header parsing happens prior to the PostReadRequest phase. all headers_in are available to you by uri translation. hmm.. the eagle book seems to say the opposite. anyway, it works :) oh, I see what you mean - the header parser phase... after reading about it again, it looks like something of a misnomer - like it does less parsing of the header and more making it available for manipulation. but I was able to change $r-uri during PostReadRequest anyway. it does make sense that all the headers must be read and available before translation I think, and this is what I've seen in practice... anyway, at this point I default to those who were around earlier and understand where the HeaderParser phase gets its name/roots... :) --Geoff -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
custom error handling logs 200 status?
Hi In the mod_perl eagle book, there's a section on writing customer error handler (pg 173-174). The example has two scripts. The first one GoFish.pm, basically returns a 500 status code and names Carp.pm as the custom error handler. I notice that if I take out the line: $r-custom_response(SERVER_ERROR, "/Carp"); and put in httpd.conf ErrorDocument 500 /Carp it'll work too (verified by telnet'ing to port). However, the access_log file will log a 500 status for the original code and a 200 status for the other. Why is that? Nancy
Re: custom error handling logs 200 status?
Nancy Lin [EMAIL PROTECTED] wrote: Hi In the mod_perl eagle book, there's a section on writing customer error handler (pg 173-174). The example has two scripts. The first one GoFish.pm, basically returns a 500 status code and names Carp.pm as the custom error handler. I notice that if I take out the line: $r-custom_response(SERVER_ERROR, "/Carp"); and put in httpd.conf ErrorDocument 500 /Carp it'll work too (verified by telnet'ing to port). However, the access_log file will log a 500 status for the original code and a 200 status for the other. Why is that? The log appears to log the status code of the actual response made to the browser. If the response is done via the ErrorDocument, the server is only serving an alternate document, which usually succeeds. The custom_response would not alter the already set status code for the request. This is only speculation on my part based on what I have seen on my own servers. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: custom error handling logs 200 status?
According to the apache documentation, the custom log directive %s logs the status of the original request. Isn't that 500 in this case? It says 500 when I telnet to the server. I don't quite understand your explanation. Can you give more details? When I have a regular ErrorDocument directive that points to a simple cgi script or a static html page, it logs the correct status code also. Are you saying in this case the actual response is a 200? If it is, how/where did that get set ? Nancy On Wed, 17 May 2000, James G Smith wrote: Nancy Lin [EMAIL PROTECTED] wrote: Hi In the mod_perl eagle book, there's a section on writing customer error handler (pg 173-174). The example has two scripts. The first one GoFish.pm, basically returns a 500 status code and names Carp.pm as the custom error handler. I notice that if I take out the line: $r-custom_response(SERVER_ERROR, "/Carp"); and put in httpd.conf ErrorDocument 500 /Carp it'll work too (verified by telnet'ing to port). However, the access_log file will log a 500 status for the original code and a 200 status for the other. Why is that? The log appears to log the status code of the actual response made to the browser. If the response is done via the ErrorDocument, the server is only serving an alternate document, which usually succeeds. The custom_response would not alter the already set status code for the request. This is only speculation on my part based on what I have seen on my own servers.
converting CGI scripts to mod_perl and memory use...
I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. Thanks! -- Dave DeMaagd - [EMAIL PROTECTED] - http://www.spinynorm.net I don't have a solution, but I admire your problem. SysAdmin/Programmer - TheImageGroup - ===|:=P
RE: CGI::Delete for Apache::Request
On Wed, 17 May 2000, Gunther Birznieks wrote: At 10:45 PM 5/16/00 -0700, Doug MacEachern wrote: well, form_fields() is descriptive and would fit nicely with the other Apache::Table methods (headers_in, etc)... something like that, i was thinking post_data, but that table also has query string data in it, which might from a get. phooey. Why not compromise and call it form_data. :) because query string data isn't part of a 'form' either :) client_data?
Re: multiple copies of a module
On Wed, 17 May 2000, Kees Vonk 7249 24549 wrote: However the URL in the guide: http://perl.apache.org/~dougm/Apache-PerlVINC-0.01.tar.gz does not exist, is there any other place where I can find Apache::PerlVINC? it's there now. and, a reminder from when it was first posted, it's not on cpan because it needs a maintainer (besides me :), anybody interested?
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. The module is currently planned to be fairly bare-boned, only adding form element generation methods for methods which will benefit from CGI.pm-style sticky values, and the parameters these methods take are likely to be a lot more restricted than CGI.pm's (not difficult, really). However, this could change in the unlikely event that we get deluged with feature requests. personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought.
Re: Setting authentication via a PerlInitHandler?
On Wed, 17 May 2000, darren chamberlain wrote:
Hi, all.
I am trying to figure out a way to set a PerlAuthenHandler (using
$r-push_handlers()) from a PerlInitHandler.
#$r-auth_type('Basic');
try $r-connection-auth_type('Basic');
i can't recall if that works quite right either.
#$r-auth_name('Test');
that should work.
#$r-requires([{requirement = 'valid-user',method_mask = -1}]);
this will not. i think a better approach, assuming you want
authentication to be conditional, is to configure Auth{Name,Type} and
require valid-user in httpd.conf so the authentication phase is triggered.
if you decide you don't need to authenticate:
$r-push_handlers(PerlAuthenHandler = \Apache::OK);
that is, you don't actually do any authentication, but apache is happy and
carries on since you return OK. otherwise, push your real authentication
handler.
Re: why a mod_perl module,Footer.pm stop cgi-bin?
On Wed, 17 May 2000, Sam Xie wrote: Hello! All, I am new user on mod_perl, and study it from the book, "Write Apache Modules with Perl and C". I installed a Handler, Footer.pm, in apache by embeding the following lines in the file apache.conf: Alias / /usr/local/share/apache/htdocs/ Location / SetHandlerperl-script PerlHandler Apache::Footer /Location It works but the scripts in /cgi-bin/ do not function at all! If I comment this handler , the cgi-bin works again. I don't know whay? Can somebody tell me the reason and how to overcome this side effect? The code and the system information is appended with this email as follow. that example only works with static text/html pages. have a look at Apache::Sandwich.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? so long as the xsub uses a FILE *, the typemap will take care of the magic. for example, Apache::send_fd() is an xsub that uses the FILE * typemap: use Apache::File (); my $r = shift; $r-send_http_header; my $tmp = Apache::File-tmpfile; print $tmp "hi"; seek $tmp, 0, 0; $r-send_fd($tmp);
Re: libapreq
On Wed, 17 May 2000, Matt Sergeant wrote: Doug, When are you releasing libapreq 0.32? i've been meaning to do that for quite a while. i have a large patch in the queue for improving multipart parsing, but already decided to wait for 0.33 to add that. which leaves a few minor details for 0.32, i'll try to make it happen soon.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... but it still adds a great deal of bloat to the server. and it's oo interface, while very slick, adds quite a bit of runtime overhead, turn the sugar sour imo.
RE: getting the hostname from a TransHandler
On Wed, 17 May 2000, Geoffrey Young wrote:
after reading about it again, it looks like something of a misnomer - like
it does less parsing of the header and more making it available for
manipulation. but I was able to change $r-uri during PostReadRequest
anyway. it does make sense that all the headers must be read and available
before translation I think, and this is what I've seen in practice...
anyway, at this point I default to those who were around earlier and
understand where the HeaderParser phase gets its name/roots... :)
yeah, the name is a little misleading. it's original intent was to allow
modules to take action based on the already parsed headers early on in
the request. which PostReadRequest can also do (and was introduced long
after HeaderParser), but is per-server, whereas HeaderParser is
per-{location,file,directory,etc}
Re: converting CGI scripts to mod_perl and memory use...
On Wed, 17 May 2000, Dave DeMaagd wrote: I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. this message from last night was intended to remind of one way to do that.. Date: Tue, 16 May 2000 23:13:19 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ANNOUNCE] B-Size-0.04 if you're not familar with B::Size, it was written a while back to answer the question 'why are my httpds so damn BIG?' there are hooks in Apache::Status to measure the size of global/lexical variables and the syntax tree. this is a debugging/educational module, for best results, run httpd in -X mode. and, do not enable on a production server, the code to measure the syntax tree can burn lots of cpu. ...
RE: CGI::Delete for Apache::Request
On Wed, 17 May 2000, Doug MacEachern wrote: because query string data isn't part of a 'form' either :) client_data? actually a large part of the time it is. for instance, search engines - most, if not all, are implemented with forms, but because they are using get instead of post, their data is delivered in the query string. see section 17.3 of the HTML 4.01 spec http://www.w3.org/TR/html4/interact/forms.html#submit-format: 'The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.' a non-form-based request containing query string information is really just the degenerate form of a form-based request. i also was going to suggest form_data() but somebody beat me to it. client_data() is more questionable, imo, cos (at least to me) it implies that the data comes from the content body of a post request. btw, see the above reference if you are still wondering where 'HTML form' is defined :)
cvs commit: modperl-site jobs.html
ask 00/05/17 15:23:47 Modified:.jobs.html Log: uhu, what a wonderful weather today. Why don't I have time to go to the beach? What a stupid world. (yup, let's blame the world I can't go to the beach). Revision ChangesPath 1.36 +5 -0 modperl-site/jobs.html Index: jobs.html === RCS file: /home/cvs/modperl-site/jobs.html,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- jobs.html 2000/04/18 03:23:45 1.35 +++ jobs.html 2000/05/17 22:23:45 1.36 @@ -24,6 +24,11 @@ ul li +!-- added 2517 [EMAIL PROTECTED] -- +a href="http://avantgo.com/corp/jobs/serverengineers.html" +AvantGo, Inc./a - San Mateo, CA + +li !-- added 2417 - [EMAIL PROTECTED] -- a href="http://www.onvista.de/jobs.html" OnVista/a - Cologne, Germany (in German)
