Re: Odd CGI interception
by chromatic (Archbishop) on Jan 12, 2001 at 01:19 UTC
|
Fastolfe is right. CGI.pm has a path_info() method which returns everything in the URI after the script name, but excluding query strings.
This is broken with IIS, which isn't a problem for you. (Jellybean gets it right, though, if you want an example.) | [reply] |
|
Isn't wasn't the pulling of the variables from the URL that was at issue, it was to hide the fact it was a cgi-bin (as per swiftone's comment ... sorta).
Now, since I have .cgi mapped to scripts, I could do this:
http://myserver.com/super.cgi/good=382/bad=10
just fine and it works as expected. What I would like to do is remove the .cgi extension from the name BUT not have to put the script into a cgi-bin only directory. Ie:
http://myserver.com/bins/super/good=382/bad=10
Though now that I think about it .. that wouldn't be TOO bad. And in fact will be my choice if I can't get it to work otherwise.
The tactic I was using before was trying to
<Location /super>
SetHandler SuperScript
</Location>
Action SuperScript /bin/myscript.cgi
That didn't work :( Mostly because I have no clue about the Action directive and even less on how Apache handles SetHandler.
Thanx!
| [reply] [d/l] [select] |
|
In instances like these, you can usually find meaningful clues by looking in your error log, but I'd start by checking: AllowOverride FileInfo is set so that Actions are permitted, and that /bin/myscript.cgi is both executable and in a directory that allows CGIs to be run (Options ExecCGI).
The other option you have (if .cgi is mapped to always run as a CGI), you can enable MultiViews with Options MultiViews so that you can access your script with or without it's extension.
--k.
| [reply] |
|
Oops - ignore my previously reply. I also thought it was
"how to extract variables" as the problem
Setting some files in the root directory of an Apache installation as executable, and others not, other than based on extension, is, as far as I can remember, exceptionally difficult.
Your best bet is to either put the file in a subdirectory where you can make every file an executable, or, if you can (i.e you don't have any files needing served as pure HTML), mark all files as executables through setting a PerlHandler Apache::Registry on / (assuming you're just going to use the Registry, rather than write your own handler...)
Tony
| [reply] |
Re: Odd CGI interception
by Fastolfe (Vicar) on Jan 12, 2001 at 00:47 UTC
|
All of this information is stored in the standard CGI PATH_INFO variable. I don't know how you'd get this with Apache::Registry, though I suspect there is a path_info method you can use somewhere to pull out the "/variablea=3892/variableb="test"" bit. It's just then up to you to split it or use it as appropriate. | [reply] |
Re: Odd CGI interception
by j.a.p.h. (Pilgrim) on Jan 12, 2001 at 00:58 UTC
|
That's not too hard, if I remember correctly. Just make the script executable, and throw it where you want it. The query string will be everything after the script name.
(Note: I've never actually done this. I've only read about it. If you want a referance on it, check merlyn's site. I know some of his columns involve things like that.) | [reply] |
Re: Odd CGI interception
by swiftone (Curate) on Jan 12, 2001 at 01:19 UTC
|
don't ask why, consider it a client requirement
For the benefit of the curious, this is usually done to fool search engines into indexing your scripts. I worked at a car auction website for a while, and they had it work like /Cars/34343/ rather than cars.cgi?34343 so that each car would be indexed. (And I did it with Apache at the time, but I've long since forgotten how I did it) | [reply] |
|
You can, in apache, ScriptAlias a dir to a
cgi-bin script, so:
ScriptAlias /rats/ /web/cgi-bin/run_rats.cgi
http://www.duo.com/rats/
runs run_rats.cgi (this seems wrong and the docs show
it for dirs only, but I've seen the dang thing work,
though I don't have access to the server). But, w/
the proper aliasing (see the scriptaliasmatch
directive too) and path_info you should be able to get
any script run on the rest of the line. Once apache finds
an executable in the path, it executes that and passes
the rest of the request in as $ENV{PATH_INFO}
a
| [reply] |
|
You probably want that to be
ScriptAlias /rats/ /web/cgi-bin/run_rats.cgi/
Note the final slash. Otherwise, /rats/foo will try to invoke run_rats.cgifoo, and you probably don't a have a file with that name.
-- Randal L. Schwartz, Perl hacker | [reply] [d/l] |
Re: Odd CGI interception
by salvadors (Pilgrim) on Jan 12, 2001 at 01:35 UTC
|
http://myserver.com/scriptname/variablea=3892/variableb="test"
In this case you can do something like:
use Apache;
# path_info will contain a leading slash. You might want to get
# rid of trailing slashes too ... YMMV
(my $path = Apache->request->path_info) =~ s#^/##;
my %param = split /[\/=]/, $path;
print "$param{variablea}:$param{variableb}"; # 3892:"test"
Usual caveats about roll-you-own CGI apply.
In production code you'll obviously want to properly cope with odd number of parameters (if you can count of specified parameters, consider using an array instead of a hash, and call it as /scriptname/3892/test instead).
And don't forget to untaint!
Tony
Tony | [reply] [d/l] |