http://qs1969.pair.com?node_id=11133407


in reply to Re^4: CGI.pm not good practice, so what is good, modern, practice for reading CGI paramters?
in thread CGI.pm not good practice, so what is good, modern, practice for reading CGI paramters?

Sorry for not replying promptly. I was out of work for a few days.

Yes -- my problem is "What's the recommended way to receive HTTP input on multiple channels, while abstracting away which channel(s) was used?".

My CGI script is tiny, has one entry point, it's not a full service, not a big application.

Preferred way would be:

#!/usr/bin/perl use CGI:Somesolution qw(getAllInputAsHash); # user input, decoded from UTF my $userinput = getAllInputAsHash({decodeUtf => 1});

I keep using CGI.pm like this:

#!/usr/bin/perl use CGI; use Encode; my $cgi = CGI->new; sub decodedForSomeTypes { $ENV{CONTENT_TYPE} =~ /boundary/ ? $_[0] : decode_utf8($_[0]); } my $params = +{ map { $_ => decodedForSomeTypes(scalar $cgi->param($_)) } $cgi->pa +ram() };
  • Comment on Re^5: CGI.pm not good practice, so what is good, modern, practice for reading CGI paramters?
  • Select or Download Code

Replies are listed 'Best First'.
Re^6: CGI.pm not good practice, so what is good, modern, practice for reading CGI paramters?
by haukex (Archbishop) on Jun 02, 2021 at 11:14 UTC

    Since you mention Unicode: Just the other day I became aware of the new CGI::Tiny, which seems to place emphasis on Unicode.