FAQ 9.16 How do I decode a CGI form?

This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.

------------------------------------------------------------ --------

9.16: How do I decode a CGI form?

(contributed by brian d foy)

Use the CGI.pm module that comes with Perl. It's quick, it's easy, and
it actually does quite a bit of work to ensure things happen correctly.
It handles GET, POST, and HEAD requests, multipart forms, multivalued
fields, query string and message body combinations, and many other
things you probably don't want to think about.

It doesn't get much easier: the CGI module automatically parses the
input and makes each value available through the "param()" function.

use CGI qw(:standard);

my $total = param( 'price' ) + param( 'shipping' );

my @items = param( 'item' ); # multiple values, same field name

If you want an object-oriented approach, CGI.pm can do that too.

use CGI;

my $cgi = CGI->new();

my $total = $cgi->param( 'price' ) + $cgi->param( 'shipping' );

my @items = $cgi->param( 'item' );

You might also try CGI::Minimal which is a lightweight version of the
same thing. Other CGI::* modules on CPAN might work better for you, too.

Many people try to write their own decoder (or copy one from another
program) and then run into one of the many "gotchas" of the task. It's
much easier and less hassle to use CGI.pm.



------------------------------------------------------------ --------

Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.

If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.

Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.

The perlfaq manual page contains the following copyright notice.

AUTHOR AND COPYRIGHT

Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.

This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.

Re: FAQ 9.16 How do I decode a CGI form?

PerlFAQ Server wrote:

> Many people try to write their own decoder (or copy one from another
> program) and then run into one of the many "gotchas" of the task. It's
> much easier and less hassle to use CGI.pm.

Randal Schwartz writes, paraphrased,

"If loading a module takes more than one-half a CPU second, it isn't worth using."

If my memory is ok, I believe that is in his number 24 article, or there abouts.

What is concealed from readers is Stein's module always creates a serious
bottleneck in a Perl script. Typically, his module will reduce script efficiency
a minimum of eight-hundred percent, and for common usage, will reduce
script efficiency twelve-hundred percent.

A task perform by custom code in less than a few seconds, will take
Stein's module close to half a minute.

Many Perl "experts" suggest to not use his module for html creation.

Until recent versions, Stein's module is not compatible with mod_perl.
Most system are loaded with CGI.pm versions which will not run
under mod_perl.

Writing correct syntax is very challenging evidenced by thousands of
articles by users, who encounter serious problems with syntax.

Stein's module is insecure unless a user knows to "turn on" security.

Sticky form variables almost always cause problems for unwary users.

His module will fail for select content types.

Select total byte count for file transfers, will cause his module to crash.


"Many people try to write their own decoder (or copy one from another
program) and then run into one of the many "gotchas" of the task."

A twisted truth. More people who write their own decoder code write
code which is highly secure, very fast, a thousand percent more
efficient, and write code which will perform any custom task. This
type of custom code is literally infinitely superior to Stein's module.

The author of this fact conceals the quality of code is not related
to the code method. Quality of code is directly related to the
quality of the skills of the code writer. He attempts to beguile
readers into believing a code method is the problem, not
the coder.

All-in-all, a mule manure FAQ. This is so because the author
displays poorly concealed deliberate bigotry; he is one those
I often refer to as a "mindless minion."

He does not have to remain so.

My opinion is use of Stein's module is number one most often
made mistake by programmers, and use of his module is the
number one worst mistake programmers make.

Readers are urged to research and read to learn their own
individual truth, which is the best of truths.

Purl Gurl

Re: FAQ 9.16 How do I decode a CGI form?

"Purl Gurl" wrote:

> What is concealed from readers is Stein's module always creates a
> serious bottleneck in a Perl script. Typically, his module will reduce
> script efficiency a minimum of eight-hundred percent, and for common
> usage, will reduce script efficiency twelve-hundred percent.

And reduce the number of stupid things in a program by 10,000%

> A task perform by custom code in less than a few seconds, will take
> Stein's module close to half a minute.

Can you show me those benchmarks?

> Many Perl "experts" suggest to not use his module for html creation.

Hence, "experts". I recently had some criticism on such an expert, he
turned out to be not even an "expert".


>
> "Many people try to write their own decoder (or copy one from another
> program) and then run into one of the many "gotchas" of the task."
>
> A twisted truth. More people who write their own decoder code write
> code which is highly secure, very fast, a thousand percent more
> efficient, and write code which will perform any custom task.

Can you give a link to the online publication of this research?

> This
> type of custom code is literally infinitely superior to Stein's
> module.

So add it to CPAN. I am happy to use it.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)

Re: FAQ 9.16 How do I decode a CGI form?

In: , "Purl Gurl" wrote:
>Until recent versions, Stein's module is not compatible with mod_perl.
>Most system are loaded with CGI.pm versions which will not run
>under mod_perl.

I've met Mr. Stein before, he is quite a skilled coder. In my opinion,
such a mundane task (parsing CGI variables) is so boring that he had
to add extra stuff just to keep it interesting.

>"Many people try to write their own decoder (or copy one from another
> program) and then run into one of the many "gotchas" of the task."
>
>A twisted truth. More people who write their own decoder code write
>code which is highly secure, very fast, a thousand percent more
>efficient, and write code which will perform any custom task. This
>type of custom code is literally infinitely superior to Stein's module.

Superior for the task at hand, perhaps. CGI.pm is quite superior if you
wanted a module that tries to be all things to all people.

I would really like to know what these ''one of the many "gotchas"'' are.

As far as I've seen, there really aren't any. (except file uploads perhaps,
I've found handling file uploads to be a time consuming task when writing
my own handlers)

Maybe Mr and Ms. FAQ will explain what these gotchas are some time. I'd be
interested in hearing them.

>My opinion is use of Stein's module is number one most often
>made mistake by programmers, and use of his module is the
>number one worst mistake programmers make.

Indeed it can be. I use CGI.pm, just because it's so easy, but then I limit my
use to the param() method because it is easy to emulate with a cusom package
later on, should I desire it)

Having said that, I would absolutely defend Mr. Stein, he IS a well
skilled coder. I want to clarify this. I see no point in being derogatory
to him or his works. (in fact, I see no reason for being derogatory toward
anyone. This arrogance in the perl community is an extreme turn off for
anyone new to perl)

>Readers are urged to research and read to learn their own
>individual truth, which is the best of truths.

I'd agree, this is one of the many reasons people should role their
own parameter parser, it'll give the programmer a better understanding
of how CGI works.

I can also understand the tone in your post as to this issue, having been
flamed a few times myself for suggesting what you suggest. There is a common
view that one should always use modules.

I'd suggest to anyone rolling their own, make it a package with a param()
method so that it works with other packages that might expect a CGI object.


Jamie
--
http://www.geniegate.com Custom web programming
guhzo_42@lnubb.pbz (rot13) User Management Solutions

Re: FAQ 9.16 How do I decode a CGI form?

nospam wrote:

(snipped)

> Purl Gurl wrote:

> I've met Mr. Stein before, he is quite a skilled coder. In my opinion,
> such a mundane task (parsing CGI variables) is so boring that he had
> to add extra stuff just to keep it interesting.

By doing so, Stein created a monster which is inefficient, buggy
and difficult to configure. I have no doubt his coding skills are
quite excellent. However, his logic is quite questionable.

> > "Many people try to write their own decoder (or copy one from another
> > program) and then run into one of the many "gotchas" of the task."

> > A twisted truth....This type of custom code is literally infinitely
> > superior to Stein's module.

> Superior for the task at hand, perhaps. CGI.pm is quite superior if you
> wanted a module that tries to be all things to all people.

Lots of people love a huge plate of spaghetti, and lots of people
have a big fat ass. =)

> I would really like to know what these ''one of the many "gotchas"'' are.

All "gotchas" are directly related to a coder's skill level. This FAQ makes
every attempt to blame gotchas on the code method. That is laughable.

Major gotcha is security. Metacharacters need to be screened. Post size
needs to be limited, which Stein's module does not do unless activated.
In short, basic security measures should be written into custom code.
Beginners usually are unaware of most security "gotchas" and the
code they write, reflects this. Again, it is not the fault of the code
as this FAQ claims. It is the fault of the coder.

I will comment, a majority of custom code usage, requires no security.
For the most part, custom parsers simply read radio buttons, check
boxes, select boxes, perhaps a bit of text such as an email address,
some registration information. Otherwords, types of data input which
cannot pose a security threat.

Taunters of CGI.pm would have readers believe the moment you use
a custom parser, you let lose a cyber monster which can whistle like
Kevin Mitnik (with whom I have been associated by some), will take over
your system, whistle a hack into your modem or broadband, access
Pentagon computers and send atomic bombs to Mars, committing
a horrific act of zenocide, leading to a movie take off on a classic
book, which makes millions and millions of big bucks. Great movie,
but I like the book better.

Bottom line is, CGI.pm groupies would have readers believe their
dicks will fall off if they don't use Stein's module. Being a woman,
that does not concern me so I don't use his module.

However, Martians scare me, but not as much as Klingons.

> Having said that, I would absolutely defend Mr. Stein, he IS a well
> skilled coder. I want to clarify this. I see no point in being derogatory
> to him or his works. (in fact, I see no reason for being derogatory toward
> anyone. This arrogance in the perl community is an extreme turn off for
> anyone new to perl)

No derogatory remarks have been leveled at Lincoln Stein. Nonetheless
I will state his creation of a monster module, does bring into question
his thinking skills.

My personal opinion is, over years, Stein came to realize, because of negative
feedback, his module is simply too big, to difficult to use, and way too inefficient.
This led to "lite" versions of his module.

Those "lite" versions are a direct acknowledgement of problems with
his CGI.pm module.

> I can also understand the tone in your post as to this issue....

I have been harping about this idiotic FAQ for years. Nonetheless,
this FAQ has never been corrected; it is still full of deceit. This
FAQ, like so many other FAQs, is fooling readers into believing
what is not true, and teaching readers to be piss poor programmers.

Each year, I take my "tone" up one step.

Next year, I WILL BE SCREAMING IN CAPITALS.

Purl Gurl

Footnote,

I have Stein's book,

Writing Apache Modules with Perl and C
By: Lincoln Stein and Doug MacEachern
Published: O'Reilly & Associates, Inc. - March 1999

It is a fairly good book, about a seven out of ten. Like
his CGI.pm, his book is misleading. Within his book,
his focus is upon mod_perl, his module and cgi usage.
A majority of his book is about his CGI.pm module and
closely related topics.

I bought his book to learn about writing Apache modules
using a C language.

Discussion of writing Apache modules and discussions
of using C language for writing those modules, both are
very minimal. There is good information, but his book
title does not reflect what is truly inside, just as those
who taunt CGI.pm neglect to tell readers, what is inside.

Re: FAQ 9.16 How do I decode a CGI form?

Purl Gurl wrote:

> Kevin Mitnik (with whom I have been associated by some),

Kevin Mitnick. Sorry Kevin.

Rather humorous Mitnick was not allowed to make any phone calls
while in prison because our government (FBI) claimed he could whistle
ring tones into a phone and take over military computers, then launch
nuclear weapons. Absolute truth, that.

Seems his whistle would dry out long before guards became suspicious
of his whistling conversation, suspicion which would come about quickly.

"Hey, what is he doing, talking to Whistler's Mother?"

Bozos.

Purl Gurl