Re: POST params with (solved)
Tom Servo wrote: > > There could be something I'm missing here, but I believe you need to use > $r->content() to get POST arguments. Beware though, that once you call > content() you can't call it again, so hang onto whatever comes out of it. > > Also...isn't it $r->args() or am I just completely missing something here? Yeah, but if you use Apache::Request then you get a param() method which works just like CGI.pm's. That is, it transparently gives you your params whether they're POST/GET/whatever. It also works really nicely with uploads. Anyways, it was a stoopid mistake, which you hit on in your reply. I had a module using a module using a module which was using CGI. Once I wrapped it in a check for MOD_PERL everything works. Thanks, Nate
POST params with
Hey all-
I'm beating my head against this issue, and I can't seem to figure it
out. The problem is I have a block with a PerlHandler for a
ticketing system app I'm writing:
SetHandler perl-script
PerlHandler Apache::TicketSystem
I'm using Apache::Request to access the params with this simple code:
sub handler {
my $r = Apache::Request->new(shift());
my %args = %{ $r->param };
# more code ...
}
When I call the app with GET params, everything works fine. When I use
POST, though, I don't get anything in %args. Reading the manpage for
Apache::Request it looks like I should automatically get the params, ala
CGI.pm. Oh yeah, and CGI.pm doesn't work either, so it doesn't seem to
be an Apache::Request problem.
Am I doing something wrong? Does not support POST params? All
the packages are at the latest rev as far as I'm aware.
perl 5.6.1
apache 1.3.20
mod_perl 1.25
libapreq 0.33
Thanks for any help.
-Nate
--
Nathan Wiger
Sysadmin and Perl Hacker
Sun Microsystems
Apache::ConfigFile just uploaded
Hey all- So, about 2 years after I originally discussed it here, I finally put the finishing touches on Apache::ConfigFile and uploaded it to CPAN. It is available in my CPAN directory: http://www.cpan.org/authors/id/N/NW/NWIGER/ This modules does the following: - Gives you offline access to any Apache style config file - Provides methods for accessing config commands and sections - Provides a dir_config() which gives you access to PerlSetVar declarations by name, just like mod_perl - Properly expands Include directives and handles paths relative to ServerRoot - Handles multiple declarations for the same context (for example, multiple VirtualHost definitions) - Provides autoloaded methods for common core functions, such as server_root() - Also has several options which can be used to extend the Apache/NCSA syntax, so that you can write a custom config module for your own applications and use this module to parse it. In any case, the module is stable but I'd be shocked it is bug-free. So if you have any comments or bugfixes I'd like to know about them. Hope you find this useful! -Nate -- Nathan Wiger Sysadmin and Perl Hacker Sun Microsystems
Re: Apache::Session::Object
Perrin- > modifying Apache::Session to support both interfaces and sending Jeffrey > the patch. This is a good suggestion. I'll try modifying Apache::Session first and sending Jeff the patch. If he doesn't want to integrate it I'll package it as a separate module. -Nate
Re: Apache::Session::Object
Perrin-
> Is there a reason you can't use the OO interface that Apache::Session
> comes with?
>
> $session->STORE('visa_number') = '7';
> print $session->FETCH('visa_number');
> $session->DELETE('visa_number');
This isn't really a documented interface - it's an overloading of the
tie methods so that the tied hash interface works. You can't find this
by reading the manpage for Apache::Session, only by reading through the
module itself or knowing enough about tie to know it's there.
> If your module is using the tied interface to Apache::Session to do its
> work, you're getting the worst of both worlds in terms of performance.
Not sure quite what you mean, maybe you can clarify? Won't You always
need to tie %session to Apache::Session:: to create the initial
object, unless I'm missing something? Are you just referring to using
FETCH, STORE, and DELETE directly inside the methods (i.e., rather than
$session{'param'} use $session->FETCH('param') ?)
> AUTOLOAD methods can be an additional slowdown if you don't cache
> AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
> time).
Good point.
> I can see reasons for creating an OO module that subclasses
> Apache::Session, but I would do it to add methods that don't map directly
> to a single hash key.
Exactly why I'm doing it:
$session->visa_number(501);
$session->visa_number;
same function, but it maps to a combination of FETCH and STORE depending
on the arguments.
-Nate
Apache::Session::Object
Hi-
I've created an object interface to Apache::Session. It's a simple
module that I've called Apache::Session::Object (seemed pretty
intuitive) that presents the following interface:
# Create new session using the default File store
use Apache::Session::Object;
my $session = new Apache::Session::Object;
my $id = $session->session_id; # get session_id
$session->{visa_number} = "4441 2001 2039 1100";
$session->param('visa_number') = "4441 2001 2039 1100"; # same
# Open existing session in the DB_File store
use Apache::Session::Object;
my $session2 = new Apache::Session::Object
($id, {Store => 'DB_File', Transaction => 1});
print $session2->_session_id;# leading _ ok
# yet another way to skin the same cat
$session->visa_number("4441 2001 2039 1100");
print $session2->visa_number;
Any comments on this? I wanted to write it to make a more consistent
interface with the other modules. It might also make sense to integrate
this with the existing Apache::Session module. The module itself is
pretty simple, just playing some tricks with new() and AUTOLOAD() to
provide a virtual OOP interface.
Thanks,
Nate
Re: Apache::Config module
> NW] In any case, I have several questions: > NW] > NW] 1. Does a module like this exist anywhere? > > You may want to take a look at AppConfig module. It does provide > generic capability to parse various kinds of config file. But I'll > be a happy user to have more spesific Apache related in this regard. Yeah, I checked out AppConfig, and I actually emailed the author about modifying it a little so I could use it as a base class possibly for Apache::Config. Unfortunately, I haven't heard anything back yet. AppConfig would be a great base class, the only problem is that: # it handles comments like this # but not like this that's the only sticking point to not being able to extend AppConfig. Hopefully I'll hear something back from him. The fix is just the addition of a \s* to a regexp. > Apache::Config will be sufficient, IMHO, as later someone might > write another module, say Apache::Config::Deploy, that syncronize > the configuration of some httpds across some networks. Not bad - I like the idea for an extension. I'll keep plugging away on it then, hopefully the author of AppConfig will get back to me as that would help save some work, but regardless the parsing of the httpd.conf is not really that hard in and of itself. I'll use the name Apache::Config unless I hear otherwise. Thanks again to everyone who responded for their input! -Nate
Re: Apache::Config module
James-
You and are are saying the same thing, just with different terminology.
I agree completely. :-)
-Nate
James G Smith wrote:
>
> Nathan Wiger <[EMAIL PROTECTED]> wrote:
> >
> > UseCanonicalName On# = 1
> > UseCanonicalName Off # = 0
> > #UseCanonicalName On# = undef (commented out)
> >
> >That way, the logic in your script/module/whatever can set a default
> >value:
> >
> > if ( ! defined($conf->{usecanonicalname}) ) {
> > # not specified, set default(s)
> > } elsif ( ! $conf->{usecanonicalname} ) {
> > # explicitly turned off
> > } else {
> > # explicitly turned on
> > }
>
> I think I would prefer it not exist in the hash if it is commented out in the
> config file (the same as not existing in the config file). Then
>
> UseCanonicalName On# = 1
> UseCanonicalName Off # = 0
> UseCanonicalName # = undef
> #UseCanonicalName On# = non-existant (commented out)
>
> Otherwise, we can't distinguish between the last two possibilities.
> --
> James Smith <[EMAIL PROTECTED]>, 979-862-3725
> Texas A&M CIS Operating Systems Group, Unix
Possible mod_perl or ??? bug?
Hi all-
On a totally different subject, I've been experiencing problems with the
interaction between CGI::Carp and Apache::Session. I find that in a
mod_perl context, if I import CGI::Carp before I import Apache::Session,
then I run into the following error:
[Thu Jun 29 13:14:03 2000] [error] (in cleanup) Can't use an undefined
value as a symbol reference at
/apache/perl/lib/site_perl/5.005/Apache/Session/Lock/File.pm line 109.
This happens if I use "PerlModule" in httpd.conf or "use" in the script
to import them. If you reverse the order, importing Apache::Session
before CGI::Carp, then everything's ok! This also only happens under
mod_perl - under a normal CGI context it works just fine. Strange.
The code this is referencing is this:
sub release_all_locks {
my $self= shift;
my $session = shift;
flock($self->{fh}, LOCK_UN); <<--- line 109
if ($self->{opened}) {
close $self->{fh} || die $!;
}
$self->{opened} = 0;
$self->{read} = 0;
$self->{write} = 0;
}
So something is screwing up the $self that should be passed to
Apache::Session::Lock::File::release_all_locks() by DESTROY(). Since
this only seems to happen when these two modules play together, it's
been difficult for me to try and find what the problem is. Anyone have
any ideas or see a similar thing on their systems? My config is mod_perl
1.24 / Apache 1.3.12 / Solaris 8.
Thanks,
Nate
Re: Apache::Config module
James-
> You might want to reconsider the usecanonicalname setting. The hash element
> should exist if and only if it appears in the configuration file. It should
> be defined if and only if it has an argument in the configuration file.
>
> Thus, the following results:
>
> UseCanonicalName
> results in $conf->{usecanonicalname} == undef
>
> UseCanonicalName Off
> results in $conf->{usecanonicalname} == 0
>
> Then use existance in the hash array to test existance in the configuration
> file. You may have already been thinking along this line. If so, then I'm
> only clarifying a point...
You're exactly right - that's why I make a distinction between 0, 1, and
undef, so:
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
#UseCanonicalName On# = undef (commented out)
That way, the logic in your script/module/whatever can set a default
value:
if ( ! defined($conf->{usecanonicalname}) ) {
# not specified, set default(s)
} elsif ( ! $conf->{usecanonicalname} ) {
# explicitly turned off
} else {
# explicitly turned on
}
This lets you default to any value you want (on or off). Does this help
clarify?
Regarding this:
> Perhaps
>
> 3. multi-level hash, i.e.
>$conf->{directory}->{'/'}->{sethandler}
>
> This is, afaik, more in-line with what the ... sections do. I
> would suggest making it so the output of this module could easily be fed into
> the mod_perl configuration engine in the sections. This gives us the
> ease of the second example with the programming simplicity of the first (i.e.,
> no new functions).
I actually like this alot. My question would be how to parse something
that didn't have one element, or that had multiple ones, for example I
can envision:
The first one exists, while the second one is (as far as I'm aware) only
theoretical. However, should they be solved as:
$conf->{perl}->{somesetting}
$conf->{somecontext}->{'/a'}->{'/b'}->{somesetting}
Input??? I just want to plan this out from the start so that as things
are added later the syntax and/or structures don't get unwieldy. I don't
want to change the "API" to such a module once it's out there.
Thanks again for the feedback.
-Nate
Apache::Config module
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
ServerName www.mydomain.com
UseCanonicalName Off
And parse it case-insensitively, returning a ref to a hash:
my $ac = new Apache::Config;
my $conf = $ac->readconf($configfile);
print $conf->{servername}; # = "www.mydomain.com";
print $conf->{usecanonicalname}; # = 0 (not undef so can test
#for defined() still)
I am also finishing up the ability to parse within contexts, such as
and . I am still unsure of the interface, I have
two ideas:
1. multi-level hash, i.e.
$conf->{"directory /"}->{sethandler}
2. individual functions, i.e.
$conf->directory("/")->{sethandler}
If anyone has any input, I'm all ears. Right now I'm leaning towards the
second one, if I can get it working. The first one is really flexible
and easy, the problem is that it's difficult to search. The second one
helps with this issue, but the downside is that new functions have to be
added if new Apache contexts are defined. I'm trying to play some tricks
with the AutoLoader ala Shell to get new functions defined on the fly.
If anyone has good ideas for a better interface, I'd also like to hear
them.
In any case, I have several questions:
1. Does a module like this exist anywhere? I saw Doug's
Apache::httpd_conf, but this only takes care of writing
a very minimal config file. I looked thru all the
Apache:: modules but didn't see one.
2. Is the name Apache::Config a good name for this module?
It seems like the obvious choice to me, and doesn't
look like it's taken. I've also played around with
Apache::ConfigFile and Apache::ReadConf, either of
which I'm open to as well (or other suggestions?).
I'm aware of the Apache and Apache::Constants modules, which do provide
Apache API methods for getting to this data that work great for
mod_perl. My goal with this module was to make it general enough to be
used to parse any Apache-style config file. That way, if you wanted (a)
write a CGI script outside of mod_perl that used httpd.conf data, or (b)
wrote a custom (maybe non-web) app that used an Apache-like config file,
you could get at the data quickly. In this way it would be like
Apache::Session, where it can work either in a CGI or mod_perl context.
Thanks for your help and input.
-Nate
