CGI is not so hard

Discussion in 'Perl Misc' started by Jürgen Exner, Aug 16, 2003.

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

    What is wrong? Do you always talk to yourself?

    jue
    Jürgen Exner, Aug 16, 2003
    #1
    1. Advertising

  2. 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
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, Aug 16, 2003
    #2
    1. Advertising

  3. Jürgen Exner

    Hudson Guest

    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, Aug 16, 2003
    #3
  4. Jürgen Exner

    Hudson Guest

    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......!!
    Hudson, Aug 16, 2003
    #4
  5. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hudson <> wrote in
    news::

    > 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-----
    Eric J. Roode, Aug 16, 2003
    #5
  6. Jürgen Exner

    Simon Taylor Guest

    Hudson wrote:
    > 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
    Simon Taylor, Aug 16, 2003
    #6
  7. Jürgen Exner

    Hudson Guest

    hehe...funny guy

    On Sat, 16 Aug 2003 06:40:14 GMT, "Jürgen Exner" <> wrote:

    >Hudson wrote:
    >[3 articles, all follow ups to his own articles]
    >
    >What is wrong? Do you always talk to yourself?
    >
    >jue
    >
    Hudson, Aug 16, 2003
    #7
  8. Jürgen Exner

    Hudson Guest

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

    >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?
    Hudson, Aug 16, 2003
    #8
  9. Jürgen Exner

    Hudson Guest

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

    On Sun, 17 Aug 2003 00:27:40 +1000, Simon Taylor <> wrote:

    >Hudson wrote:
    >> 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, Aug 16, 2003
    #9
  10. Hudson <> wrote:
    >>> You use environment varibles to grab the input from the form.

    >>
    >>Huh? Certainly not for POST.

    >
    > 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 SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Aug 16, 2003
    #10
  11. Hudson <> wrote:

    > 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]


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Aug 16, 2003
    #11
  12. Jürgen Exner

    Si Ballenger Guest

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

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

    >Top-posting is seen as rude here.
    >
    >Please don't top-post unless you _mean_ to be rude.
    >
    >--
    > Tad McClellan SGML consulting
    > Perl programming
    > Fort Worth, Texas
    Si Ballenger, Aug 16, 2003
    #12
  13. Jürgen Exner

    hudson Guest

    >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, Aug 17, 2003
    #13
  14. Jürgen Exner

    hudson Guest

    >> 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.


    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, Aug 17, 2003
    #14
  15. Jürgen Exner

    hudson Guest

    On Sun, 17 Aug 2003 00:51:45 GMT, "David Formosa (aka ? the Platypus)"
    <> wrote:

    >On Sat, 16 Aug 2003 02:09:15 -0700, Hudson
    ><> wrote:
    >
    >> 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.

    >
    >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
    hudson, Aug 17, 2003
    #15
  16. Hudson <> wrote:
    > and soap is even easier:
    > from: http://www.w3.org/TR/SOAP/#_Toc478383490
    >
    > Example 1 SOAP Message Embedded in HTTP Request
    >


    <snip>

    >
    > 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\
    --
    Jonathan Stowe |
    <http://www.gellyfish.com> | This space for rent
    |
    Jonathan Stowe, Aug 17, 2003
    #16
  17. hudson wrote:
    >>> 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.

    >
    > 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
    Jürgen Exner, Aug 17, 2003
    #17
  18. Jürgen Exner

    Juha Laiho Guest

    said:
    >On Sun, 17 Aug 2003 00:51:45 GMT, "David Formosa (aka ? the Platypus)"
    ><> wrote:
    >
    >>On Sat, 16 Aug 2003 02:09:15 -0700, Hudson
    >><> wrote:
    >>
    >>> 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.


    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).
    --
    Wolf a.k.a. Juha Laiho Espoo, Finland
    (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
    PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
    "...cancel my subscription to the resurrection!" (Jim Morrison)
    Juha Laiho, Aug 17, 2003
    #18
  19. "hudson" <> wrote in message
    news:...
    > >Hmm. Are you not aware that '&' (as a separator) is deprecated?

    >
    > 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.

    > >This is just one of the reasons why rolling your own parser is not a good
    > >idea. You might search for
    > >
    > > sub parse_params {
    > >
    > >in a recent (non-broken) copy of CGI.pm to see how it's done.

    >
    > thanks, that is an interesting tip
    >
    > >FWIW, I shudder to think of what your next few lines of code would have
    > >been.

    >
    > 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);


    <snip>

    > $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
    William Alexander Segraves, Aug 18, 2003
    #19
  20. hudson <> writes:
    > 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
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
    Eric Schwartz, Aug 19, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jürgen Exner

    Re: CGI Perl "use CGI" statement fail

    Jürgen Exner, Jul 31, 2003, in forum: Perl
    Replies:
    0
    Views:
    1,229
    Jürgen Exner
    Jul 31, 2003
  2. Shailan
    Replies:
    2
    Views:
    874
    Shailan
    Dec 15, 2003
  3. John Smith
    Replies:
    0
    Views:
    2,994
    John Smith
    May 15, 2006
  4. thedarkman
    Replies:
    5
    Views:
    384
    Raymond Schmit
    Apr 6, 2009
  5. Dr. John P. Costella

    Running CGI through browser from local hard disk

    Dr. John P. Costella, Jul 16, 2003, in forum: Perl Misc
    Replies:
    11
    Views:
    234
    William Alexander Segraves
    Jul 19, 2003
Loading...

Share This Page