Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

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 (Pope)
on Nov 06, 2013 at 17:19 UTC ( #1061449=note: print w/ replies, xml ) Need Help??


in reply to Re^7: 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

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.


Comment on Re^8: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
Re^9: Shortest/quickest way for Perl to take POST data it receives and send a POST request with this data to another URL?
by Your Mother (Canon) on Nov 06, 2013 at 19:08 UTC

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

      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

        I see what you are saying and I'm all for wrapping existing CGIs in adaptors, when possible, but I disagree on principle. This is like insisting that mixing hash access with Moousueusue-based code isn't a problem. Yes, it works, yes it's probably future proof in many cases and somewhat transparent. No, it's still not correct and mixing the two approaches increases the cognitive load/overhead and potential bugs. You insist your future devs be adept at a dead-end and the idiosyncrasies that made it such instead of embracing ideas that span several high-level languages and foster tremendous re-use and cross-pollination. Probably the single best app engine for PSGI stuff is Python/C: uWSGI. It supports PSGI because it was easy.

        I feel pretty credible here. I still write CGI.pm based code, I even think, to the appalled reactions of many monks, that it's a perfectly cromulent library for HTML formatting. I'm not the modern for modern's sake monk. I'm the modern for the love of pity why am I still working 90% of the time on code this 1995-awful monk. I would never foist any of this on someone at $work and the times when I end up revisiting this kind of stuff in my own projects I only have regret that I didn't see it might grow/outlast the shoddy/quick path I gambled.

        You also gloss the fact that once one knows enough to be able to wrap CGIs to PSGI, which isn't always easy or possible, one knows better than to write the stuff that needs to be wrapped in the first place.

      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.

        I tend to agree. That was not the OP's question though and it is easy to imagine the real use case is not a straight-up proxy. And exploring Perl options is more fun, well, not so much today apparently, and edifying.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1061449]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2014-12-18 05:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (42 votes), past polls