First of all, using request_uri is, as I said, as far as I know. Anytime I've seen something like this done, it's been with request_uri, and it works for me, so I'm happy. But maybe I'm wrong!
Alex would be the man to explain the difference rather than me, I still consider myself an amateur. With the speed the web is developing, I think I always will be!
Anyway, before you go any further, I'm talking about Apache here, so if you're running another webserver, this (probably) won't apply. Next, check to see if mod_rewrite is compiled into the server. If you don't know how to do that, email your server administrator and ask him. Also check to see if you're allowed to use .htaccess files, because some sysadmins turn them off.
Also, I would advise you to have a look at the official documentation on mod_rewrite at
www.apache.org/docs/mod/mod_rewrite.html and the invaluable guide written by Ralf Engelschall, the writer of mod_rewrite at
www.engelschall.com/pw/apache/rewriteguide/ , because it's one of the more complicated of the modules. It's also one of the most powerful, or "bloody handy" in dahamsta speak. And Ralf has put some nice examples on that webpage.
Ok, so for simplicity's sake, I'll use your example:
http://whatever/directory/data1/data2
So you want everything under /directory/ to be processed by index.cgi right? Well, I'm guessing that the reason that you're getting an error is because either a) you're setting up a loop with mod_rewrite (it's trying to rewrite to /directory/, trying to rewrite to /directory/ etc etc) or b) there's a problem with the script itself.
The easiest way to go about it is to create a .htaccess file in your
document root directory, with something like this:
RewriteEngine on
RewriteRule ^directory.* /cgi-bin/script.cgi [T=application/x-httpd-cgi]
And stick your script into your cgi-bin. You see, it doesn't *matter* where you keep the actual script, because the user will never know that the page is actually being processed by it, to them it will look like they're viewing a regular file in a regular directory. The directory itself doesn't even have to exist, matter of fact I wouldn't recommend you create one first day, because you'll just confuse the issue!
So a simple script to test this would be like:
Code:
#!/usr/bin/perl
# This'll report errors back to the browser.
use CGI::Carp qw/fatalsToBrowser/;
# Now split the uri into an array.
@dirs = split("/",$ENV{REQUEST_URI});
# And splice it to remove the first two elements.
# Remember that there's a forward slash at the start too,
# so there will be an empty entry in the first element.
# The second element is of course /directory/, which we
# don't need.
splice(@dirs,0,2);
# Print a header
print "Content-type: text/html\n\n";
# Now print out each element in the array.
# You should get back each dir requested
# under /directory/
foreach $dir (@dirs) {
print "$dir<br>";
}
exit;
So to use this in a useful manner, you would then assign the data you got back from the directory names into your own variables. Like in a shopping cart, if your request_uri was /directory/item1/ you could use that like:
$item = $dirs[0];
And "item1" would now be in $item. And you could use that anyway you wanted then, maybe to pull details from a database, or to parse a file with that products details.
I know the whole thing is a bit complicated at the start, but when you get used to it, you'll realise how invaluable it is, particularly on large sites, or in product catalogues and the like. Set it up to interface with a powerful program like Links or dbMan, or better still, an SQL database, and you've got a very powerful tool in your hand. So to speak.
Cheers,
adam
[This message has been edited by dahamsta (edited July 29, 1999).]
