Should I use .pl or .cgi for Perl web script files?

HI. I created two files 'hello.pl' and 'hello.cgi' with the code below.

#!/usr/bin/perl
print "Content-type:text/html\n\n";
print "hello world";

I can view the page via both http://www.mydomain.com/cgi-bin/hello.pl and http://www.mydomain.com/cgi-bin/hello.cgi. Which one is more sense in Perl web dev?

BTW, the directory of 'cgi-bin' created by my VPS server, Do I need contact with my VPS support to remove it or j开发者_StackOverflow社区ust remain it like this URL style? Maybe http://www.mydomain.com/perDev/hello.cgi is better?

It doesn't really matter which extension you use. You could configure your server to treat .potato as a CGI file if it pleases you.

My personal preference would be to use .cgi or even no-extension at all if it will work. The main reason for that is you give out a bit less information to anyone who may wish to attack your script. It's a minor thing--don't rely on this as a security measure. This is a chicken-soup security precaution (it can't hurt).

The benefit of not using .pl is so slight that you may decide to use .pl for the simple fact that it is shorter, and it would still be a good enough reason as far as I am concerned.

Do whatever pleases you.

If at all possible, try to not use extensions, or even exposing real file names if you can. You can do this with apache mod_rewrite rules, or a dispatching system with your framework (Dancer, CGI::Application, Catalyst, etc).

Some do it because it obfuscates things a bit and might provide a bit of extra security (but not much if any). But I do it because it then doesn't tie you down to a particular implementation. What starts out as some simple scripts can turn into a full blown application and people get annoyed if you invalidate their bookmarks. So by picking something abstract you have more freedom to do what you want in the future.

Mine are usually named .fcgi (I use FastCGI rather than plain CGI), but the user never sees the program's name thanks to a bit of URL rewriting in .htaccess. It's much nicer for users to be able to just go to http://mysite.com/ instead of http://mysite.com/mycode.fcgi, after all.

Functionally, it's identical regardless of extension. As daotoad said, the server can be configured to recognize that something is a CGI executable based on any file extension you choose, or by its location in the file system (sites using a /cgi-bin/ directory will usually treat everything in that directory as a CGI program regardless of name or extension), or even individually-named files with no apparent pattern or connection between them.

Use either no extension or something generic like .cgi.

daotoad is correct about .pl being a minor security leak, but more importantly it pegs your URLs to your current implementation language. URLs should be a permanent location for information. Should you decide in the future to rewrite your application later in another language you'll be stuck with the legacy .pl extension.

The same applies for command line programs. Just write command not command.pl and let the #! line do its job. After all, we don't run ls.c.

mpeters is also correct in that you should avoid linking your URLs to actual files, again not so much for security purposes but to make the URL a permanent interface. For example, you want http://example.com/login not http://example.com/cgi-bin/login.

All other things being equal, I'd name it .cgi to remind the coder that it is not just another Perl script and has robustness requirements special to CGI.

Use none.

Because URLs should be meaningful and technology independent.

Modern Perl web frameworks such as Dancer or Mojolicious can help you to achieve that.