in reply to Re^6: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
in thread Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?

If I didn't know Plack, no, but I do (and am trying to improve my knowledge in the area) so, yes. PSGI middlewares (Plack::Middleware) for example add a huge amount of drop-in utility that otherwise range from difficult to dirty to hack up in a hand rolled version built for a single purpose. The script could proxy or not by a map of URLs, do custom authentication in front of some, run an arbitrary number of other apps/CGIs (Catalyst/Dancer/PHP/Whatever) alongside a proxy (which would require more than a one liner in this case), display show|hide timing/debug/env in the page with JS. Each addition being one to five or six new lines of code. You also get multiple deployment options, uWSGI, Starman, Twiggy, FCGI, and several more.

Nothing wrong with bare bones Perl. Kits like Plack give you easy room for growth and adjustment.

  • Comment on Re^7: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?

Replies are listed 'Best First'.
Re^8: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
by BrowserUk (Patriarch) on Nov 06, 2013 at 17:19 UTC
    If I didn't know Plack, no, but I do

    Hm. And that makes it appropriate to advocate this to the OP when this is sufficient for his needs?


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      :P Any webdev doing CGI instead of PSGI is hurting his or her career and free time. And there was already zentara's answer, I was just adding to the bounty. The PSGI spec is simple too; easier and more consistent than the CGI spec. I think your photo analogy is funny but not on point. PSGI is the true utilitarian option and more like Legos than the kitchen sink.

      Real world sidebar: I'm currently in the first week of what I expect to be about four weeks of rewriting some CGI code that was "sufficient" when it was written. The marathon rewrite is necessary to fix something that could have been addressed with one line of Plack middleware. One dev's sufficient is the next dev's WHY OH GOD WHY?! Perl is the poster child for technical debt because it's so easy to "Just Do It." I think posting alternative strategies benefits everyone and each can choose according to his or her own level of masochism. Double :P

      Update: FTR, my code is a few lines shorter than the LWP example zentara gave, does more (meaning it's more verbose than necessary), and doesn't use the problematic CGI->Vars which joins multi-values with null bits which aren't considered/handled in the example.

        FTR, my code is a few lines shorter than the LWP example zentara gave, does more (meaning it's more verbose than necessary), and doesn't use the problematic CGI->Vars which joins multi-values with null bits which aren't considered/handled in the example.

        Personally, I wouldn't be looking to use CGI or PSGI.

        Installing and invoking either behemoth to decode headers and post data, only to then exactly re-encode them for the forwarded request seems a futile exercise, when you can easily arrange for most serious webservers to re-write or re-direct the url without need for any code. And the very definition of technical debt.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        P Any webdev doing CGI instead of PSGI is hurting his or her career and free time.

        That cannot possibly be true, see CGI::PSGI