nicht angemeldet
Moin moin!
[quotes rearranged]
Ich benutze das immer so, es gibt zwar andere Möglichkeiten über cgi, aber das Modul nutze ich nicht so gerne.
Ich auch nicht, aber es gibt einen Grund, warum CGI.pm immer empfohlen wird, naemlich damit solcher Code wie Deiner nicht verwendet wird. Auf den ersten Blick faellt mir auf:
Datenstrom einlesen
sub read_data
{
# Datenstrom lesen (POST)
if (lc($ENV{'REQUEST_METHOD'}) eq 'post')
{
read (STDIN,$eingabe,$ENV{'CONTENT_LENGTH'});
@eingabe=split(/&/,$eingabe);
Hier wird nicht die Moeglichkeit gelassen, die einzelnen Parameter mit ; statt & zu trennen. Das ist zwar kein MUST, aber immerhin ein SHOULD.
foreach $i (0..$#eingabe)
{
$eingabe[$i]=~ s/+/ /g;
$eingabe[$i]=~ s/%(..)/pack("c",hex($1))/ge;
($feldname,$wert)=split(/=/,$eingabe[$i],2);
Hier fliegt das Script auf die Schnauze, wenn ein Feldname ein = enthaelt. Die Decodierung muss *nach* dem split fuer Feldname und Wert separat erfolgen.
if ($feldname)
Hier versagt es, wenn ein Feldname eine einfache 0 ist.
{
${lc($feldname)}=$wert;
}
Und hier werden noch viel mehr moegliche Feldnamen ausgeschlossen. Christian hat ja schon was dazu gesagt. Wenn jemand einen Feldnamen schickt, der kein gueltiges Perlsymbol ist, dann war's das fuer Dein Script.
# Datenstrom lesen (GET)
if (lc($ENV{'REQUEST_METHOD'}) eq 'get')
Was bitte ist mit HEAD requests?!
Ausserdem ist so das POSTen an eine URL mit Querystring nicht moeglich. (Weiss aber nicht, ob CGI.pm das kann.)
wenn Dein <input name="blablabla" value="test"....> lautet,
ist $blablabla == "test" !!!
Der Vorteil hierbei ist eben auch, daß es direkt in der im HTML benannten Variablen landet.
Vorteil? "Vorteil" ist nicht ganz genau das Wort, das mir zu Namespace pollution und potentiellen Sicherheitsluecken einfaellt.
So long
--
Rule of thumb -- every time Microsoft use the word "smart," be on the lookout for something dumb.
-- http://www.fourmilab.ch/webtools/demoroniser/