Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Odd CGI interception

by mr.nick (Chaplain)
on Jan 12, 2001 at 00:40 UTC ( [id://51197]=perlquestion: print w/replies, xml ) Need Help??

mr.nick has asked for the wisdom of the Perl Monks concerning the following question:

This is a combination Apache/PERL question.

I would like to create a CGI that can be accessed in the following fashion:

http://myserver.com/scriptname/variablea=3892/variableb="test"

In other words, I need it to act like a directory and have it's variables passed as if they were subdirectories (don't ask why, consider it a client requirement).

I was think that Apache would have the ability to do this either with a Handler specification (the best choice) or a RewriteRule (the worst choice, I could do this myself, but would rather not).

Does anyone have any suggestions, either direct examples or perhaps pointers to Apache documentation which would help me with this?

Thanks again! -- mr.nick.

Replies are listed 'Best First'.
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.)

      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!

        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.


        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

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.
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.)

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)

      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

        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

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://51197]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-04-25 15:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found