Gossamer-Threads has a pretty cool mod_perl setup. You can get a
dedicated server or a shared account. Each shared account has its own
apache process, which means that you can log in and control (i.e. stop /
start / restart) your own modperl httpd.
All the mod_perl processes are behind a
Geoffrey Young wrote:
??? I do not know what you mean, my GET request _has_ a content-lenght
header! For HEAD, I just do not calculate the expencive data for my body.
that is exactly what I mean - if you include a C-L header on a GET then you
are supposed to have one for a HEAD request as well,
Chris Faust wrote:
What would you suggest for a situation where a user is entering in their
credit card information, using their back button and submitting again and
then complaining about a double charge?
I would suggest that you need to create some kind of transaction ticket.
For example,
Chris Faust wrote:
Folks,
I need to expire a page so if a user uses his back button, he will not
be able to the previous page (which as a form etc.)..
Sorry if this sounds troll-ish, but IMHO if your application is designed
in such a way that you need to sacrifice standard browser
assuming you don't want to use basic or digest http authentication (aka
popup boxes, which manage this kind of thing for you) typically the second
(and future) script is kept unaware of the username/password. instead, the
authentication script verifies the user/password and generates some kind
Jo S [EMAIL PROTECTED] wrote:
Well, my idea is to build a persistent IMAP module to use with mod_perl.
So, unfortunetly this is not the solution.
It seems that you need an IMAP proxy which keeps your connections
persistent on which you can connect speedily.
There are already programs that do
The idea is to get always the same apache process to handle requests
from the same client.
I need this because I want to use something that is in memory, in a
mod_perl variable.
You need a session to uniquely identify clients. There are a horde of
module on CPAN to help you do that.
?
Cheers,
--
Jean-Michel Hiver - MKDoc Ltd
http://mkdoc.com/
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Problem: Can't load ' ../auto/DBI/DBI.so for module
DBI.
Well, you could try Net::MySQL instead which is pure perl.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette:
I S wrote:
Thanks. Yet, the web site and practical mod_perl book says that
|Can't load DBI| or *similar error for the IO module or whatever
dynamic module mod_perl tries to pull in first*. The solution is to
re-configure, re-build and re-install Perl and dynamic modules with the
following
Perrin Harkins wrote:
On Mon, 2004-03-15 at 16:23, Jean-Michel Hiver wrote:
Yes, what I'm trying to achieve is get Apache::Registry to send custom
404 pages - just like under mod_cgi.
I assume that means you want to be able to run the exact same script
under mod_cgi? And you don't want
Ethan Joffe wrote:
I am trying to use Apache::DBI with RH9.0 defaults (apache2.0.40-21.9,
modperl1.99_05-5, DBI 1.32-5)
I put the following line in my startup.pl:
PerlModule Apache::DBI;
PerlModule is for apache config files.
startup.pl is just a regular perl script so you should use a plain
Description:
The following CGI script:
print EOF;
Status: 404 Not Found
Content-Type: text/plain
Document not found
EOF
Results in the following:
Document not found
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
HTMLHEAD
TITLE404 Not Found/TITLE
/HEADBODY
H1Not
Didn't Geoff already answer this question for you? You can't do this in
this way with PerlSendHeader turned on. I'm not sure if your goal here
is to send your own custom 404 error or to have apache pick it up and
send the ErrorDocument without your content. If you explain what you're
trying to
Perrin Harkins wrote:
On Mon, 2004-03-15 at 16:23, Jean-Michel Hiver wrote:
Yes, what I'm trying to achieve is get Apache::Registry to send custom
404 pages - just like under mod_cgi.
I assume that means you want to be able to run the exact same script
under mod_cgi?
Well, yes
Once you run the above at the very beginning of your script, it'll
pull out $r out from thin air from that point on. that's exactly what
+GlobalRequest does.
True, but since it is not necessary to do this first operation with mp1,
when you use Apache::compat with mp2 this should be done for
Hi List,
I am trying to get a rather large-ish web app to run with apache 2 /
mod_perl 1.99. I have installed the latest RPMs for Fedora from FreshRPMs.
PerlModule Apache2
PerlModule Apache::compat
PerlOptions +GlobalRequest
PerlOptions +SetupEnv
I have a very strange behavior with
I would consider it a bug, but mod_perl (through the current release)
populated %ENV when the first Perl*Handler runs, which may have been before
or after translation (which is where path_info becomes known). if you
specifically move that PerlInitHandler to a PerlHeaderParserHandler I'd
suspect
Dave Rolsky wrote:
I'd like to create a wrapper around Apache::Session that would
Well if you write 'a wrapper around Apache::Session', then I think you
should call it Apache::Session::Wrapper since that's what you say it is...
automatically create the session based on either a query/POST
.
Authentication can be done using HTTP authentication without using
cookies or URI session tracking (which is, frankly, very ugly).
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage
Nope. That's a very bad idea. I don't want to go and rewrite all my code to
use Apache2::Request and dozens of other modules, which work exactly the same
as before, but their guts are different.
I would tend to agree with Jay though: I would consider Apache and
Apache2 are two different
Speedup Apache::Registry scripts!
Not so long ago I was enquiring the mod_perl list on how to capture
Apache::RegistryNG's output by subclassing it. Thanks to the list help,
here is this new module.
MKDoc::Apache_Cache is a drop-in replacement for Apache::Registry. It
uses Cache::FileCache as a
your global variables
and localize them in your main cgi script:
local $SomePackage::SomeVariable = undef;
local %OtherPackage::SomeHash= ();
etc.
And see how it goes.
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel
,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
to bother you guys with this stuff... I'm only -reluctantly- ever
invoking the dark powers of the mod_perl gurus spirits when I'm super-stuck,
which unfortunately is the case right now :(
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel
you take in order to write one? I've
contemplated the idea but I'm stuck with capturing Apache::Registry or
Apache::RegistryNG's output.
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
and writes
it into '/tmp/foo'. (Attached file).
However, I cannot get this same module to actually send correctly the captured
output... Have you got any suggestions?
Thanks a bunch,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
27 matches
Mail list logo
