Re: Get those parameters without CGI.pm

[Anonymous Monk]

many thanks for inspiration ;)

sub get_cgi_params_parse ($;$){
  my ($str, $params) = @_;
  my $res = {};
  
  $str =~ tr/+/ /;
  foreach (split /&/, $str){
    my ($one, $two) = split /=/, $_;
    $one =~ s/%([\da-fA-F][\dA-Fa-f])/pack("C", hex($1))/eg;
    $two =~ s/%([\da-fA-F][\dA-Fa-f])/pack("C", hex($1))/eg;
    if (exists $res->{$one}){
      $res->{$one} .= "\n".$two;
    }else{
      $res->{$one} = $two;
    }
    $params->{$one} = $res->{$one};
  }
  
  return $res;
}
sub get_cgi_params (;$$$$){
  my ($get_str, $post_str, $cookie_str, $force_get) = @_;
  my $res = {_names => [], get => {}, post => {}, cookies => {}, vars 
+=> {}};
  $force_get = 0 unless defined $force_get;
  
  $cookie_str = $ENV{'HTTP_COOKIE'} unless defined $cookie_str;
  if ($cookie_str){
    foreach (split /; /, $cookie_str){
      m/^(.+?)(=(.*))?$/;
      $res->{cookies}->{$1} = $3;
    }
    }
  
  if ($force_get or $ENV{'REQUEST_METHOD'} eq "GET" ){
    $get_str = $ENV{'QUERY_STRING'} unless defined $get_str;
    $res->{get}  = get_cgi_params_parse $get_str,  $res->{vars} if $ge
+t_str;
  }
  if ($ENV{'REQUEST_METHOD'} eq "POST"){
    read(STDIN, $post_str, $ENV{'CONTENT_LENGTH'}) unless defined $pos
+t_str;
    $res->{post} = get_cgi_params_parse $post_str, $res->{vars} if $po
+st_str;
  }
  return $res;
}

[rjha94]

It is interesting to see how people are against the idea of writing a replacement of CGI.PM because new code is worse to begin with. However one big point in favor of this replacement code is that you can see how CGI works under the hood.

365 days of using CGI.PM as a library can never teach you that. I may not want to read the CGI.PM library precisely because it is mature and full of error checks and utilities that do not let me see the "essence". so such code at least has a __teaching__ aspect and should be applauded for that.

And maybe it is okay to reinvent the wheel once in a while otherwise we can never make it rounder..

[Anonymous Monk]

It is interesting to see how people are against the idea of writing a replacement of CGI.PM because new code is worse to begin with.

Hi, you must be new :)

For years after CGI.pm appeared, people were still brokenly reinventing it

For years after CGI.pm was made a core perl module, people were still brokenly reinventing it, and then asking why their code is broken and how to fix it

It is such a frequent and impressive waste of time that Ovid wrote use CGI or die; and Ovid's CGI Course 10 years ago, 6 years after CGI obsoleted all imitators

And maybe it is okay to reinvent the wheel once in a while otherwise we can never make it rounder..

Yes, its ok to reinvent a wheel, like reinventing aspirin, but it has to be an obvious improvement, and you have to be able to make it yourself and be prepared for the appropriate amount of criticism

But, if you're advocating hitting yourself over the head with a rock as a replacement for aspirin , expect the worst :)

Take a look through the bug reports and changes files some time -- anyone reinventing CGI.pm is smart enough to make thrice as many mistakes :)

See CGI::Simple, its CGI.pm minus the html generation code (ie, its faster), written 10 years ago, through advanced reuse concept of "copy" and "paste"

See also PSGI/Plack, written 2 years ago, it is the next generation , beyond the CGI (note, not CGI.pm )

[cavac]

Sometimes it's a good thing, sometimes it isn't. See 935499 for a discussion on that topic.

What you have to really understand by heart when attempting such a project: Those matters are far more complex than they look. I know, i wrote my own Webserver.

While the basics - e.g. getting the most used stuff working - is most times not that difficult, the devil is often in the details. You'll have to make the more obscure features work (like handle multipart forms for file uploads in your case and also parse headers like if-modified-since). You'll do error handling, handle interrupted connections, intentionally misformed data (hacking attempts) and such.

And - if you publish your solution and people base their projects on it, it would be your implied responsibility to keep the API stable while still continuing development.

If you are willing to embark on that journey, you are very welcome.

Don't count on it beeing an easy journey or a quick one. If you succeed, it will be a personal triumph for you that may include widespread adoption of your solution. But you better plan to work hard for months or years to get to that point.