|
Apache::Emulator - Emulates the mod_perl request object from CGI |
args()get_remote_host()method()path_info()uri()
Apache::Emulator - Emulates the mod_perl request object from CGI
This document refers to version 0.01 of Apache::Emulator, released October 29, 2001.
use Apache::Emulator;
my $r = Apache::Emulator->new( %config );
I work in a firm that uses Netscape as its front-line webserver, but I prefer to code my Perl using mod_perl rather than CGI. I also have an account on an internal Apache server running mod_perl, but I don't have admin rights to restart the webserver while I'm developing code [nor am I allowed to run my own copy of Apache]. I also like to develop web applications that *will* run on a CGI platform, but will run *very fast* on a mod_perl platform.
The solution? Emulate mod_perl within the CGI environment. It's slower than traditional CGI, but you can develop for both platforms and deploy to mod_perl once your code is finished. No more apache restarts!
I've added functionality as I've gone along, so don't expect every Apache method call to work. If it's documented below, it exists. If it isn't documented, it doesn't exist, and you should send me the code to implement the function. That's the way open source works.
Much of the documentation is a straight copy from the Apache pods. If a method doesn't work as documented, tell me. Even if you don't have a fix, telling me that there's a problem will usually elicit the right response.
Some stuff will never work. Subrequests are likely to be in this category. I don't use them very often, so I'm not too bothered.
use Apache::Emulator;
my $r = Apache::Emulator->new( PerlHandler => 'Your::ModPerl::Module' );
my $r = Apache::Emulator->new( PerlHandler => 'Your::ModPerl::Module', PerlSetVar => { MYCONFIG => '/var/myapp.conf', ADMIN => 'nigel:dave:jon' });
After you've constructed your Apache::Emulator object, pass it into the handler subroutine of your mod_perl module. Everything should work perfectly. Maybe.
args()The $r->args method will return the contents of the URI query string. When called in a scalar context, the entire string is returned. When called in a list context, a list of parsed key => value pairs are returned, i.e. it can be used like this:
$query = $r->args;
%in = $r->args;
get_remote_host()Lookup the client's DNS hostname. Don't expect double-reverse lookups to work.
Returns true if the client is asking for headers only, e.g. if the request method was HEAD.
method()Returns the request method. It will be a string such as ``GET'', ``HEAD'' or ``POST''.
path_info()The $r->path_info method will return what is left in the path after the URI --> filename translation.
The $r->protocol method will return a string identifying the protocol that the client speaks. Typical values will be ``HTTP/1.0'' or ``HTTP/1.1''.
The request line sent by the client, handy for logging, etc.
uri()Returns the requested URI minus optional query string.
Get or set the content type being sent to the client. Content types are strings like ``text/plain'', ``text/html'' or ``image/gif''. This corresponds to the ``Content-Type'' header in the HTTP protocol.
Get or set the reply status for the client request.
Get or set the response status line. The status line is a string like
``200 Document follows'' and it will take precedence over the value
specified using the $r->status() described above.
prints!
Send the response line and all headers to the client. Takes an optional parameter indicating the content-type of the response, i.e. 'text/html'.
Returns the value of a per-directory variable specified by the ``PerlSetVar'' directive (see CONSTRUCTOR, above).
Nigel Wetters (nwetters@cpan.org)
Copyright (c) 2001, Nigel Wetters. All Rights Reserved. This module is free software. It may be used, redistributed and/or modified under the same terms as Perl itself.
|
Apache::Emulator - Emulates the mod_perl request object from CGI |