nicht angemeldet
hi,
-Einige sagen Get ist begrenzt, weil eine URL nicht unendlich sein kann.
-Ein anderer behauptet alte Browser können max 255 Zeichen übertragen.
-Noch ein anderer sagt es sind 2048 Zeichen.
-Weitere Meinungen setzten Werte je nach Serverfähigkeit von 255,1024 und 2048 Zeichen.
Das kann schon sein, ist aber letztendlich kein Thema.
Dann wird noch empfohlen, bei größeren Datenmengen lieber Post statt get zu verwenden. Was soll man von all diesen Infos halten, bzw. was stimmt jetzt???
Die Empfehlung hat einen anderen Grund: Bei GET liegen die Daten im URI als sog. Query_String. Das landet bei jedem Proxy und zuletzt beim Webserver in der Logdatei ;)
Deswegen: Post. Da wird nur der Locator geloggt. Die Datenmenge ist jedoch dieselbe wie bei GET, wenn bei einem POST encode="application/x-www-form-urlencoded", das ist der Default, benutzt wird. Da wird aus einem 'ä' => %C3%A4 (sog. Percent-Encoding). Kurzum: Was bei einem POST gesendet wird, sieht mit o.g. encode="application/x-www-form-urlencoded" genauso aus wie ein QUERY_STRING. Aus den 2 Bytes eines UTF-8-'ä's werden nunmehr 6 Bytes und der Euro ist noch teurer ;)
Kleinere Datenmengen bekommst Du mit encode="multipart/form-data", da werden die Roh-Bytes gesendet, allerdings kommt dann zwischen den einzelnen Parts noch die Boundary (Textstring und Leerzeilen) dazwischen.
Kurzum: Begrenze die Eingabe mit Javascript (das ist zeichenorientiert) und mach Dir keine Sorgen wegen der Datenmenge, die brutto übertragen wird, die dürfte geschätzterweise stets doppelt bis dreimal so groß sein, es kommen ja auch noch die Header hinzu für den Request.
Serverseitig gibts fürs CGI-Modul noch
$CGI::POST_MAX=1024 * 100; # max 100K posts
zum Vermeiden kleinerer Denial of Service attacks. Und da haben wir noch einen Grund, die method="POST" zu verwenden: POST::MAX kannst Du selbst festlegen.
Ein QUERY_STRING (GET) hat sicher auch eine max. Länge aber es wäre jetzt müßig die einschlägigen RFCs zu wälzen und das rauszusuchen.
Viele Grüße!
MudGuard