[thelist] Perl problem and question

Dwayne dwayne at iconys.com
Mon Aug 6 22:30:44 CDT 2001


On Monday 06 August 2001 19:38, Matthew Brooks wrote:
> Dwayne <dwayne at iconys.com> wrote:
> >					using CGI.pm for nothing more than
> >a redirect is silly, but using _anything_ is better than writing your own
> >form parsing code.
>
> May I ask why? I'm just curious.

hmm..i stated that a bit strongly. i can think of worse things, but i do 
think there are good arguments for using a standard library.

> Security is not an issue - of course I use strict, the -w flag, and taint
> mode. Or does CGI.pm go further?

as far as security goes, one thing most hand rolled url decoding routines 
i've seen don't do is check how much data is being uploaded. if you're not 
checking the size of what's being fed to your form, some malicious individual 
can try to upload a bigger file than the server can handle.

(of course, you have to explicitly enable this in CGI.pm as well. if you're 
using it, you should have something like:

$CGI::POST_MAX = 1024*100;
$CGI::DISABLE_UPLOADS = 1;

in your script).

but there are other reasons...if anyone else is going to have to maintain 
your scripts, knowing that they use a standard library is a great help. i 
know what $CGI->param() does, but if i come across %form = parseURL($url), 
i'll want to check the code. a similar argument applies if you're working 
with others.

today, you're script only needs to handle form parsing. what if you expand 
it, and you need to parse mulitpart/form data, or set cookies? if you're 
already using a library that inlcudes some basic level of functionality, this 
is much easier. it also keeps you working within the same paradigm.

> The form parsing code (i.e. just the code
> that gets the variables passed from the form) that I use is less than 15
> lines, pretty basic stuff. I often just copy and paste it from one script
> to another, so I'm not actually writing the code anew each time.

cutting and pasting a bit of code into a script doesn't seem like a lot of 
work, but it can lead to maintainance problems. what if you find a bug in it? 
you'll be scouring old scripts for various versions of the function. (this is 
more an argument for keeping frequently used functions in their own library, 
but if you can use functions in a library that someone else is maintaining, 
that's even better).

> There's no
> overhead from using CGI.pm (however small that overhead may be).

i wouldn't want to give the impression that the overhead from CGI.pm is 
_small_, exactly, more that it's often invoked as the Great Satan in 
situations where it's only a minor bogeyman.

(if this is a real issue for you, check out CGI::Minimal. it handles form 
parsing, and not much else. it's tiny).

> I've thought about using CGI.pm before, but never really seen the point
> when it's so easy with straight Perl in the script. What does everyone
> think?

use the tools that are right for you...i like CGI.pm for a number of reasons, 
which may or may not apply to you:

- part of the standard library - i can count on it always being available, 
and just a use statement away,
- i use it nearly exclusively for my CGI needs, so i'm familiar with it, and 
i'm always working within it's paradigm (damn, same buzzword twice in one 
email. i should be smacked, or promoted to management), 
- maintainability. if i can use someone else's module, it's one less thing 
for me to worry about,
- it can do pretty much anything i'd want - form data, uploads, cookies and 
headers are all taken care of. extras include automagically persistent form 
fields.
- debugging. this is maybe my favorite thing. being able to debug scripts 
from the command line, or by feeding parameters in from a text file is 
_sweet_.

as always, your mileage may vary.

- dwayne




More information about the thelist mailing list