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?

    Jürgen Exner, Aug 16, 2003
    1. Advertisements

  2. Also sprach Hudson:
    Huh? Certainly not for POST.
    And somewhere else you ask:
    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 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 v. Parseval, Aug 16, 2003
    1. Advertisements

  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, 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
  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
    Hash: SHA1

    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?

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

    Version: PGPfreeware 7.0.3 for non-commercial use <>

    -----END PGP SIGNATURE-----
    Eric J. Roode, Aug 16, 2003
  6. Jürgen Exner

    Simon Taylor Guest

    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
  7. Jürgen Exner

    Hudson Guest

    hehe...funny guy
    Hudson, Aug 16, 2003
  8. Jürgen Exner

    Hudson Guest

    OK, sorry...just the guys that are jumping on me
    Hudson, Aug 16, 2003
  9. Jürgen Exner

    Hudson Guest

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

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

    It is also reading input from stdin.
    Tad McClellan, Aug 16, 2003

  11. 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, Aug 16, 2003
  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." ;-)
    Si Ballenger, Aug 16, 2003
  13. Jürgen Exner

    hudson Guest

    If you are rude, you might expect rudeness in return.
    geez...Tad, sorry, but I only found out this morning that top posting
    is rude
    hudson, Aug 17, 2003
  14. Jürgen Exner

    hudson Guest

    read (STDIN, my $input, $ENV{'CONTENT_LENGTH'}); 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
  15. Jürgen Exner

    hudson Guest

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


    Jonathan Stowe, Aug 17, 2003
  17. 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.

    Jürgen Exner, Aug 17, 2003
  18. Jürgen Exner

    Juha Laiho Guest

    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, 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).
    Juha Laiho, Aug 17, 2003
  19. 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.
    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.,
    Here's where you might have done better with

    my @kv = split (/[&;]/, $input);
    You may have noted that in the parse_params subroutine of, that both
    the params and values are unescaped, whereas you have only processed the

    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


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


    Bill Segraves
    William Alexander Segraves, Aug 18, 2003
  20. 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 Schwartz, Aug 19, 2003
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.