You can easily utilize ScriptAlias directives in Apache for this, which allows you to tell the webserver that URLs like /serve.pl/arguments/go/here should be executed by the CGI script, and that serve.pl is not to be interpreted as a directory name. The stuff in the URI after serve.pl will be placed in $ENV{PATH_INFO}, so modifying your code is easy. You should be able to just change your code from using param('page') to the PATH_INFO environment variable instead, and everything should still work.

Here's how you can get ScriptAliases to work:

If you have access to the httpd.conf file, you can add a ScriptAlias for the individual script in question. It can be anywhere in the httpd.conf file and will look something like this:

ScriptAlias /serve.pl "/usr/local/apache/htdocs/serve.pl"
[download]

So now, all you have to do is rewrite your HTML parser to use the URI format instead of the query-string argument format. Now when you have a page /serve.pl/foo/bar.html, which has a link to ../perl.html in its HTML, the browser will do all the work on its own and come up with a URL that your script can accept as-is.

The only work that really needs to be done is with absolute links. But that's trivial! Just prepend the location of your script to the beginning of all HREFs starting with a slash. /index.html becomes simply /serve.pl/index.html.

Best of luck,

blokhead

If you are using Apache, you can also use the cgi-script handler instead of ScriptAlias. So, in general, if your server.pl script is already running on the webserver, you can use the PATH_INFO trick to pass the URIs to the script.

You do need to watch out for root-relative URIs though; say you've got an html page with the following code:

<img src="/pix/image.gif">
<img src="pix/image.gif">
[download]

When the HTML page is called as /index.html the URIs for the images will be:

/pix/image.gif
/pix/image.gif
[download]

When you call the page as server.pl/index.html the URIs will be:

/pix/image.gif
/server.pl/pix/image.gif
[download]

By the way, using the BASE tag might also help.

-- 
Joost       downtime n. The period during which a system
            is error-free and immune from user input.
[download]

That didn't sound right. Let me offer an example:

/usr/local/apache/content holds the "content" html just as your /perl/index.html does.

/usr/local/apache/htdocs is where the webserver serves up pages.

My program wraps the content html in headers and footers (as well as running the whole thing through Template Toolkit), then saves the result as an .html somwhere under /usr/local/apache/htdocs/

Thus my users don't have any execution time for "flat" pages, only with actual dynamic content, but my unit doesn't have to maintain the navigation on every page because the build process drops it in place. Our setup is a little complex, with a database holding the relationships between pages, and the build process generating a different local navigation for each page, but you can season to taste.

It's not a concept I can take any credit for, it's been done for a while (Laziness, after all). Template Toolkit ships with a helper program that does something like this, and it's a simple script to do it with most other template systems (I only have experience with Template::Toolkit and HTML::Template, but the concept holds true for anything with HTML output).

I've got a bunch of programs that handle a website I'm working on, one of which is a main "server" program. It basically gets a single parameter: page location (for example: http://.../serve.pl?page=/perl/index.html). This works very nicely.

Have you tried your script to see how ‘nicely’ it works with pages that aren't in your document directory. You don't want things like this to work:

• http://.../serve.pl?page=/etc/passwd
• http://.../serve.pl?page=../../../../../../etc/passwd

You'd improve security if you just passed in the basename of the file as the CGI parameter, with the path and extension being hardcoded in the Perl script and added there.

But even that may not be secure. Do not put your site live without checking the vulnerabilities mentioned in this Phrack article. This still applies even if you go for URL rewriting as suggested in other answers.

Smylers

sub reduce_path ($) {
        # given a path which may contain multiple instances of ..
        # generate an absolute path
        my @path = split /\//, shift;

        my @new_path;
        while (scalar @path) {
                $_ = shift @path;
                if (/^\.\.$/o) { pop @new_path or
                        croak "I can't recurse past my root\n";
                } elsif (/^.$/o) {              # do nothing.
                } else { push @new_path, $_;
                }
        }
        return join ('/', @new_path);
}

# usage:
print reduce_path '/foo/bar/../baz', "\n";
print reduce_path '/foo/bar/../../baz', "\n";
print reduce_path 'foo/bar/baz/../', "\n";
[download]

sub absolute_url ($$) {
    my ($base,$url) = @_;
    $base =~ s{/[^/]*$}{/};                 # remove file from base
    $url = $base.$url;                      # append base and url
    1 while ( $url =~ s{/[^/]*/\.\./}{/} ); # remove ..
    return $url;                            # all done!
}
[download]