CGI is not so hard

[Jürgen Exner]

Hudson wrote:
[3 articles, all follow ups to his own articles]

What is wrong? Do you always talk to yourself?

jue

 

[Tassilo v. Parseval]

Also sprach Hudson:

Why is everyone around here acting like CGI is some big secret? I read
the RFC's on HTTP, etc...it is no big deal....GET, HEAD, POST, etc...

When you are writing your code, you write it for the method you are using.

You use environment varibles to grab the input from the form.

Huh? Certainly not for POST.

You don't let untainted stuff into your shell, etc....

So...what's the big deal?

I think you guys are all trying to get contracting jobs and that's why you all
are acting like this ;-)

And somewhere else you ask:

what kind of programmers are you all? geez......!!

Why don't you find out yourself? To get an idea on what those very
people you are poorly trying to attack have done so far go to
http://search.cpan.org/ and look up their name. After that you'll have a
change to see the code they have written and released. Compare that with
your own works and you'll quickly have to acknowledge that they aren't
as lazy, clueless and unwilling to read RFCs as you try to convey.

Or grep a perl source distribution for their names and learn that some
of them are distributing to the perl-core. That alone makes your
statements utterly ludicrous.

If I do any of the above for your name (which happens to be non-real,
btw), I'm sure I'll come up with nothing.

Tassilo

 

[Hudson]

Why is everyone around here acting like CGI is some big secret? I read the RFC's
on HTTP, etc...it is no big deal....GET, HEAD, POST, etc...

When you are writing your code, you write it for the method you are using.

You use environment varibles to grab the input from the form.

You don't let untainted stuff into your shell, etc....

So...what's the big deal?

I think you guys are all trying to get contracting jobs and that's why you all
are acting like this ;-)

 

[Hudson]

ok...I have really had it with this group...I think this is lame that you all
don't know http or cgi or soap and can only think in modules.

what kind of programmers are you all? geez......!!

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ok...I have really had it with this group...I think this is lame that
you all don't know http or cgi or soap and can only think in modules.

what kind of programmers are you all? geez......!!

Why are you insulting *everyone* in the group for a bunch of conversations
you've been involved in with a few people over the course of maybe two
hours? (at least, as far as I can tell, by looking at the headers).

Am I missing something?

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPz4d+mPeouIeTNHoEQJtAwCeOaMobWbs0I2MEGfGHbjXsCa3O3gAn1Zj
iOQ6eRfXZKu5elGxYojneiIh
=r7Xh
-----END PGP SIGNATURE-----

 

[Simon Taylor]

ok...I have really had it with this group...I think this is lame that you all
don't know http or cgi or soap and can only think in modules.

what kind of programmers are you all? geez......!!

Folks, please stop feeding this troll!

If we ignore it long enough, it will get hungry and it will move
away.... ;-)

Simon Taylor

 

[Hudson]

hehe...funny guy

 

[Hudson]

OK, sorry...just the guys that are jumping on me

 

[Hudson]

I'm not a troll...but don't worry, I am not going to continue this.

 

[Tad McClellan]

read (STDIN, my $input, $ENV{'CONTENT_LENGTH'});
my @kv = split (/&/, $input);
for my $kv (@kv)

etc....that's not just grabbing an environmental varible?

No, that is not just grabbing an environmental varible (sic).

It is also reading input from stdin.

 

[Tad McClellan]

OK, sorry...just the guys that are jumping on me

If you are rude, you might expect rudeness in return.

Top-posting is seen as rude here.

Please don't top-post unless you _mean_ to be rude.



[snip TOFU]

 

[Si Ballenger]

On Sat, 16 Aug 2003 15:22:39 -0500, (e-mail address removed) (Tad
McClellan) wrote:

"Begging the question is what one does in an argument when one
assumes what one claims to be proving." ;-)

 

[hudson]

If you are rude, you might expect rudeness in return.

Top-posting is seen as rude here.

Please don't top-post unless you _mean_ to be rude.

geez...Tad, sorry, but I only found out this morning that top posting
is rude

 

[hudson]

read (STDIN, my $input, $ENV{'CONTENT_LENGTH'});

No, that is not just grabbing an environmental varible (sic).

It is also reading input from stdin.

OK...so I confused stdin with an environmental varible (TM)

can't I still be a Perl hacker, even if I don't know all the terms ;-)

 

[hudson]

Thats the advantage of modules. They abstract away the complexict and
the knowlige of a subject. I don't have to have deep knowlige of Soap
or cgi because I can make use of the highly skilled persons knowlige
that has been embedded into the module.

yes...but it is so cool to know soap or http and it is really pretty
simple...just read one or two RFC's and something about soap and then
you can interface all you want via IO::Socket

 

[Jonathan Stowe]

and soap is even easier:
from: http://www.w3.org/TR/SOAP/#_Toc478383490

Example 1 SOAP Message Embedded in HTTP Request

not so hard...just connect to a socket, send header and request...you
guys here are really lamers ;-)

Well, no, sending that specific request wouldn't seem to be so difficult on
the face of it, but of course then you find yourself with the issue of
interpreting the response, dealing with a fault response if there is one,
and handling the possibility that the service might alter the version of
SOAP that is being used among other things. SOAP::Lite will handle these
things for you without you having to reinvent the wheel.

*I* do understand SOAP and have read the specification, and indeed could
hand code implementations *for languages where no reusable library was
available*, however as libraries are available in the majority of languages
that I am ever likely to use (hell, I even made the gSOAP libray work with
Informix 4GL) this is an unlikely thing to happen.

I don't think anyone here is suggesting that you shouldn't be familiar
with the specification of a particular protocol that you might find
yourself working, they just understand good software engineering practice
and will tend to encourage you to make use of a well tested piece of
reusable code rather and discourage you from making your own incomplete
and possibly buggy implementation.

HTH

/J\

 

[Jürgen Exner]

OK...so I confused stdin with an environmental varible (TM)
can't I still be a Perl hacker, even if I don't know all the terms ;-)

Sure. It just makes it difficult for _you_ to understand the documentation
(and how do you program without being able to read them?) and it makes it
difficult for _us_ to discuss because we don't know if you meant chair or
table when you said sofa.
Don't get me wrong, everyone started somewhere some time ago. But if you
want to communicate with other programmers (or even just program for
yourself) you better learn the terms of the trade or communication will be
severely confused.

jue

 

[Juha Laiho]

(e-mail address removed) said:
You've already shown that you don't even know the area of HTTP/CGI as
well as the author of the CGI module does, so you've managed to prove
the point of using the modules.

yes...but it is so cool to know soap or http and it is really pretty
simple...just read one or two RFC's and something about soap and then
you can interface all you want via IO::Socket

Yes, the basic model in those is easy. Yet there are quite a list of
details to remember (the separator character in CGI param lists being
one of them). And to make your program work correctly, you'll have to
get all those details correct.

Also, if it so happens that to get something done, you're only allocated
three hours time, you don't want to spend any time on such pieces of
code that you know someone else has already written (and that have
been widely tested in various of real-life conditions). And definitely
you don't want to end up writing code for all those details again and
again for each of your projects. So, this boils down to writing [and
MAINTAINING!] your own module to implement some functionality (or making
a cut-n-paste of code implementing some functionality) when you're
writing code for some new project where that functionality is needed.

Now, consider a situation where you have done this your own way; having
few hundreds of CGI programs around, each having the CGI functionality
copied from one of the others, but slightly modified, as you realized it
didn't quite work correctly for this specific case. Perhaps even the CGI
functionality is partly intermixed with your application logic, because
you could that way optimize away one variable and three operations.

Then something in the specifications change (like the change from &-
delimited param lists to ;-delimited ones). What do you do to make your
scripts compliant with this change? You hand-edit each of the scripts.
What does the "dumb" programmer who used the module? He replaces the
module, once per each machine where he has those scripts running. With
bad luck there may be couple of scripts that did depend on some detail
of the module interface that did change along with the other changes in
the module, but that's the extent of the change.


One important measure of programmer ability is the maintainability of
the produced code (don't know about you, but in the real life code
is written to be used and modified, not to be thrown away). Modules
inherently improve maintainability, so avoiding the use of them is a
very worrying sign in a programmer.

Of course, if you can show that a module is so badly implemented that
you can do the same thing better, then it's good to have a discussion
with the author of that module, providing your insights and proposals
for improvement -- or even writing a competing module, if the author
doesn't like to implement your proposed changes.

Writing small pieces of throwaway code to learn how some things work
(like for learning CGI), is just fine. But that doesn't give any grounds
for starting a crusade against use of modules, and there's no reason
to brag that you're so smart you can do something that can also be
achieved by a module (especially when you in the same message claim
that what the module does is trivial - and later still show you don't
know the details of even those trivialities). And as the module (with
the details implemented correctly) already existed, you weren't even
creating anything new.

I also did my own code testing to learn/verify some issues of the CGI.
After satisfying my curiosity (and after starting to write real code
where CGI was needed), I switched over to use the module. This is "best
of both worlds" solution: I'm not wasting my time (nor that of my
employer) reimplementing and maintaining something someone else already
does. Still when it is needed, I also know the underlying technology
(which, as you say, is not hard).

 

[William Alexander Segraves]

this is just code for fun and is working fine for me...but I guess
code for production has to have higher standards

Indeed it does. If you never deploy your code to a place where nefarious
attacks can exploit possible security holes, I suppose you can do as you
wish. OTOH, if you place resources that are shared by all at risk, you are
held to a higher standard.

thanks, that is an interesting tip


maybe something like:

$my_system_vanishes = `$kv{untainted_value}`;

Well, that's not what I had in mind. I should have been explicit; but I had
not found the quotation from another thread (Re: hand crafting ...), i.e.,

read (STDIN, my $input, $ENV{'CONTENT_LENGTH'});
my @kv = split (/&/, $input);

Here's where you might have done better with

my @kv = split (/[&;]/, $input);

for my $kv (@kv) {
(my $key, my $value) = split (/=/, $kv);

$value =~ tr/+/ /;
$value =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg;

You may have noted that in the parse_params subroutine of CGI.pm, that both
the params and values are unescaped, whereas you have only processed the
values.

Failing to deal with $key in similar fashion (to what is done for $value) is
a common mistake committed
by beginners, e.g., your parsing scheme wouldn't work well with any instance
of the submittal of

'a key like this';

because it would leave it in the form

'a+key+like+this'

I'll leave it to you to conjure up other possibilities where this will,
well, cause you some inconvenience.

Cheers.

Bill Segraves

 

[Eric Schwartz]

I'm still not 100% with you on CGI.pm. People around here seem very
loyal to it, but I have read in a lot of different places that it is
too large and slow, etc.

Keep in mind who's doing the writing. Here: recognized experts in the
languages, often with several books on the language under their
belts. There: some guy with a website?

The blessing of the Internet is that nobody has to get permission
to put anything they want to on line. This is also its curse.

-=Eric