Ian Langworth wrote:

It sounds like the name of HTTP is more appropriate:

     ...uri, pathinfo, params, method, headers, etc.

     ...adds to HTTP::Request to provide session() method

     ...response code, content, headers, etc.

     ...extends response.write() to encode JSON

Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
their functionality.

Maybe it's too servlety.

It is :)

It is probably the *proper* way, but definetely not the *efficient* way. You rarely do real HTTP handling when you use CGI.

A general, simple CGI handling module fits into 200 lines, including POD. Imagine like

sub parseQueryStupidAndWrong {
       my $self = shift;

       $ENV{'QUERY_STRING'} || return {};

       my @pairs = split(/&/, $ENV{'QUERY_STRING'});
       my %query;
       foreach my $pair (@pairs) {
               my ($key, $value) = split (/=/, $pair);
               $key =~ tr/+/ /;
               $key = whatever::url_decode($key);
               $value =~ tr/+/ /;
               $value = whatever::url_decode($value);
               if ($query{$key}) {
                       $query{$key} .= ", $value";
               } else {
                       $query{$key} = $value;
       return \%query;

You don't really need more. IMHO a CGI module parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, COOKIES), and that's it. It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use.

- Cs.

Reply via email to