Opened by borisd at 2015-12-29 00:09
Über Sinn und Unsinn von CGI.pm habe ich schon vor Jahren nachgedacht. Ich nenne es veraltet aus verschiedenen Gründen und zum Parsen von HTTP-Request-Parametern setze ich es schon lange nicht mehr ein.
Vor Allem erscheint mir die Logik der Vermittlung zwischen application/x-www-form-urlencoded oder multipart/form-data in CGI.pm nicht schlüssig, weil das in CGI.pm mit der Request-Method verknüpft ist. So gibt es außer den genannten beiden Enctypes mittlerweile eine Reihe weiterer Enctypes wie z.B. application/json oder application/xml um nur zwei zu nennen. Ein Parser sollte also mit derartigen Enctypes umgehen können und das unabhängig von der Request-Methode.
Wünschenswert ist daher ein von der Request-Method unabhängiger Layer welcher um beliebige Enctypes erweiterbar ist. Ob die Daten serverseitig aus STDIN oder QUERY_STRING gelesen werden ist eine ganz andere Sache, denn es gibt außer well known Request Methods wie GET, POST, PUT u.a. theoretisch unendlich viele Requestmethoden. Bspw. kann ein HTTP-Client seine Request-Methode ASDF nennen und einen Message Body mit einem proprietären Enctype senden der serverseitig aus STDIN gelesen wird.
Mein Schichtenmodell zeigt die Unabhängigkeit und die universelle Verwendbarkeit. Es ist beliebig erweiterbar.
Last edited: 2015-12-29 12:22:52 +0100 (CET)
Vor Allem erscheint mir die Logik der Vermittlung zwischen application/x-www-form-urlencoded oder multipart/form-data in CGI.pm nicht schlüssig, weil das in CGI.pm mit der Request-Method verknüpft ist. So gibt es außer den genannten beiden Enctypes mittlerweile eine Reihe weiterer Enctypes wie z.B. application/json oder application/xml um nur zwei zu nennen. Ein Parser sollte also mit derartigen Enctypes umgehen können und das unabhängig von der Request-Methode.
Wünschenswert ist daher ein von der Request-Method unabhängiger Layer welcher um beliebige Enctypes erweiterbar ist. Ob die Daten serverseitig aus STDIN oder QUERY_STRING gelesen werden ist eine ganz andere Sache, denn es gibt außer well known Request Methods wie GET, POST, PUT u.a. theoretisch unendlich viele Requestmethoden. Bspw. kann ein HTTP-Client seine Request-Methode ASDF nennen und einen Message Body mit einem proprietären Enctype senden der serverseitig aus STDIN gelesen wird.
Mein Schichtenmodell zeigt die Unabhängigkeit und die universelle Verwendbarkeit. Es ist beliebig erweiterbar.
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
# hier werden die jeweiligen Layer geladen sub _parse_rawdata{ my $self = shift; if( $self->{CONTENT_TYPE} eq 'multipart/c-eav' ){ require cEAV; $self->{eav} = cEAV->decode_eav( $self->rawdata ); $self->{param} = $self->{eav}->{param}; } elsif( $self->{CONTENT_TYPE} eq 'multipart/eav' ){ # like c-eav } elsif( $self->{CONTENT_TYPE} eq 'multipart/form-data' ){ require ParseMultipart; $self->{STDIN}->seek(0,0); $self->{param} = ParseMultipart->parse_multipart( $self->{STDIN} ); } elsif( $self->{CONTENT_TYPE} eq 'application/json' ){ require JSON; my $json = JSON->new; $self->{json} = $json->decode($self->rawdata); $self->{param} = $self->{json}{param}; } else{ # Default Content-Type # Parameter: Name => [Value], application/x-www-form-urlencoded $self->{param} = $self->qparse( $self->rawdata ); } }
Last edited: 2015-12-29 12:22:52 +0100 (CET)