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.

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.

I tend to agree. That was not the OP's question though

Really? I thought that was exactly what he asked for?

A possible solution is, of course, to parse the data using CGI, then to form and send a POST request using LWP, but this seem un-Perl-like and inelegant. Surely there's a simpler solution?

---

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

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.

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

Now that is even more ridiculous than your previous statement

You can write crap for every backend. The difference between CGI and PSGI is trivial , there is no cognitive load

sub psgier { my( $env ) = @_; my $req = Plack::Request->new( $env ); my $query = $req->param('query'); my $res = app_logic( $query ); return $res; } [download]

sub cgier { my $q = CGI->new; my $query = $q->param('query'); my $response = app_logic( $query ); print $q->header; print $response; } [download]

If you used any kind of abstraction like CGI::Application... then there is no difference of any kind between running on PSGI or CGI

PSGI is great, bashing CGI is weak