swiftone has asked for the wisdom of the Perl Monks concerning the following question:

When possible (and it's often not), I like to use "clean" URLs:
http:/my.domain.com/script.cgi?1234

This is nice for all sorts of aesthetic and usability reasons. My problem is getting it to play nice with CGI.pm. Here's the usage I've come up with, but I'd appreciate it anyone could alert me to potential problems with this: 

my $page = new CGI;
$page->param('WhateverFieldItIs',$page->param()) if $page->param() == 
+1;

[download]

Replies are listed 'Best First'.
Re: Clean URLs and CGI.pm
by Trimbach (Curate) on Jun 11, 2001 at 20:04 UTC
    What you're talking about is referencing a CGI as the result of an ISINDEX search as opposed to invoking it via a parameter list. CGI plays quite happily either way. From the CGI docs:
    FETCHING A LIST OF KEYWORDS FROM THE QUERY: 
    @keywords = $query->keywords

    [download]
    If the script was invoked as the result of an <ISINDEX> search, the parsed keywords can be obtained as an array using the keywords() method.

    FETCHING THE NAMES OF ALL THE PARAMETERS PASSED TO YOUR SCRIPT: 

    @names = $query->param

    [download]
    If the script was invoked with a parameter list (e.g. ``name1=value1&name2=value2&name3=value3''), the param() method will return the parameter names as a list. If the script was invoked as an <ISINDEX> script and contains a string without ampersands (e.g. ``value1+value2+value3'') , there will be a single parameter named ``keywords'' containing the ``+''-delimited keywords.

    Gary Blackburn
    Trained Killer

[reply]
[d/l]
[select]
      But it really isn't the result of an ISINDEX. (I think). Here's an example:

      Let's say I'm writing a search script against some database. You can search, you can follow links from the results page to give you more results, you can go to an "advanced search" page and set all sorts of options. So normally, this will be a standard GET or POST setup with multiple values.

      However, because I'm a difficult person, I want it to also accept one parameter without a key-value pair (It will know which field this value belongs to). For example, most search engines have many options, but will work just fine with /search.pl?q=search+terms. I don't want the "q=" or whatever though. I want users who are in the know (and HTML writers who want VERY simple links) to have: "search.pl?term"

      So I can't just use param(), because I don't know which manner the script is being called by. The code I posted works just fine, I just wanted to make sure I wasn't making some grevious error or missing something obvious.

      Did I understand your reply correctly?

[reply]
        If you want your CGI called with "search.pl?term" that's fine... all you have to do is $q->param(keywords) in your CGI to access whatever follows the "?" in your URL. If someone calls your script like this "search.pl?field1=term" then the "term" value will appear in $q->param(field1). Just set some if/then's to decide which is which, maybe like this: 
        if ($q->param(keywords)) {
   $field = $q->param(keywords);
} else {
   $field = $q->param(field1);
}

        [download]
        Or maybe I don't understand what you want. The 3 main ways of getting data into CGI.pm are via ISINDEX, POST, and GET. Since POST and GET both boil down to key/value pairs they are (to CGI.pm at least) interchangeable. ISINDEX is just a value without a key and is handled in param(keywords). Now why can't you use param again?

        Gary Blackburn
        Trained Killer

[reply]
[d/l]
Re: Clean URLs and CGI.pm
by tadman (Prior) on Jun 12, 2001 at 05:20 UTC
    I'm a clean URL fanatic, some would say to the point of extremity. In fact, I would go so far as to say that, apart from images and other unusual media, that sites should not contain filename extensions at all.

    The reason I despise extensions is that one day you have a simple HTML page called "something.html", which you later upgrade to, say, "something.phtml" when someone decides to use PHP on it. Now every single link to that page is broken, and has to be repaired or redirected. Later, perhaps, the page is modified again, this time into a CGI called "something.cgi" which breaks your links all over again.

    If you use Apache's MultiViews, it will figure out what you mean without benefit of the extension. If you think this is too slow, use Squid as a turbocharger, but for low-mid volume sites it seems to work fine without any sort of accelerant.

    I would even go so far as to specify a URL such as:     http://my.domain.com/script/1234 Which is about as basic as you can get. The '1234' will be passed via CGI to your application which can process it as you will. Further, you can make up your own format for the URL data, without worrying about '&' or '?'. As long as you use taint, and check carefully (as you should anyways), then you may find this a lot simpler, especially when many parameters make for an unwieldly URL.
[reply]
[d/l]
Re: Clean URLs and CGI.pm
by shotgunefx (Parson) on Jun 11, 2001 at 20:01 UTC
    I'm not exactly sure what you mean about CGI not playing nice. Are you worried about extra parameters when you call self_url or something?

    If so, make a new CGI object and only copy the params you want and then call self_url on that.

    -Lee

    "To be civilized is to deny one's nature."
[reply]
      Sorry for not being clear. I want to use CGI.pm to make sure that I take advantage of all the security checks. (Otherwise I'd just copy QUERY_STRING).
[reply]
Re: Clean URLs and CGI.pm
by RatArsed (Monk) on Jun 11, 2001 at 20:03 UTC
[reply]
[d/l]
      In your mind perhaps, but not in the minds of anyone not familiar with how CGI works.
[reply]

Back to Seekers of Perl Wisdom