in reply to Odd CGI interception

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

Replies are listed 'Best First'.
Re: Re: Odd CGI interception
by mr.nick (Chaplain) on Jan 12, 2001 at 01:28 UTC
    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

    [download]
    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]

In Section Seekers of Perl Wisdom