Alternative zu CGI - Rostis Framework - #188645 (Allgemeines zu Perl)

rosti

2018-07-17 11:15

User since
2011-03-19
3513 Artikel
BenutzerIn

Also, den Enctype application/x-www-form-urlencoded zu parsen ist ja nun wirklich keine Hexerei:

Code (perl): (dl )

# Public und unabhängig verwendbar
# application/x-www-form-urlencoded
sub qparse{
    my $self    = shift;
    my $rawdata = shift;
    my %param = ();
    # Punkte in Parameternamen erlauben
    my @pie = split /[;&]/, $rawdata;
    foreach my $p(@pie){
        my ($pname, $val) = split(/=/, $p, 2);
        next unless $pname;
        next unless defined $val;
        $val =~ s/\+/ /g;
        $val =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
        push @{$param{$pname}}, $val;
    }
    return \%param;
}

Vorher ist lediglich zu klären woher die Daten kommen. Ist $ENV{CONTENT_LENGTH} > 0 werden die Daten aus STDIN gelesen. Gibt es einen $ENV{QUERY_STRING}, wird der geparst. Wobei es natürlich auch beide Quellen geben kann. CGI.pm hat eine ziemlich proprietäre Logik hierzu mit dem gravierenden Nachteil daß das nicht um weitere Content-Types erweiterbar ist.

Neben dem übermittelten Enctype, der sich im Header Content-Type und damit in %ENV wiederfindet, ist also nicht etwa die Request-Method entscheidend fürs Parsen der Parameter. Zumal die Request-Methode eine beliebige Zeichenfolge sein kann! So kann es also auch mit Request-Methode GET einen Messagebody geben, machbar ist das! Und die neue FetchAPI erlaubt ohnehin Custom Request-Methodes -- man sollte und kann also seinen Parser nicht davon abhängig machen.

MfG