Rouven: POST-Datenmenge zu groß?

Hallo,

ich habe ein größeres Problem:
Ich muss von einem einzigen, skriptgenerierten, Formular eine Menge Daten abschicken, da diese auf der "Zielseite" des nicht mehr zur Verfügung stehen. Es handelt sich dabei um Datensätze. Derzeit habe ich die Datensätze auf einen String konkateniert im Stil von xxx, xxx, xxx und das Ergebnis in eine hidden-Feld meines Formulares geschrieben. Das Formular wird dann mit POST+SUBMIT() abgeschickt.
So weit, so gut bei geringen Datenmenge, kaum wird aber die Datenmenge mal etwas größer (kann ich schlecht schätzen 5-10kb) streikt der Server mit einem Internal-Server-Error. Mir steht leider die Server-Konfiguration nicht zur Verfügung.
Hat jemand einen Vorschlag?

Einzige bisher denkbare Alternative wäre es, sich die "Datensatzposition" also z.B. 3 zu merken, dann nur den Datensatz 3 zu posten, im Zielformular den Rest mit dem Satz 3 zu machen, und dann das Formular mit 4 wieder aufzurufen - gefällt mir aber nicht so gut und wird wohl auch um einiges langsamer sein als ein einziger Durchlauf des Skriptes.

Danke für alle Hilfe !

  1. Hallo,

    So weit, so gut bei geringen Datenmenge, kaum wird aber die Datenmenge mal etwas größer (kann ich schlecht schätzen 5-10kb) streikt der Server mit einem Internal-Server-Error.

    5-10 KB? Das ist _gar nichts_! Andreas Korthaus verschickt laufen MBytes an Daten quer durchs Internet per POST und bekommt keinen Internal Server Error. Was verwendest Du denn, um das ganze Auszuwerten? Vielleicht stürzt dein Script/Programm/sonstwas einfach ab und deshalb Internal Server Error. Hast Du Zugriff auf Dein error_log?

    Grüße,

    Christian

    1. Ja, aber das sagt mir gar nichts:

      { Apache 2.0.39, Win2K SP3, IBM Net.Data }
      Das Skript tut aber noch gar nichts, bereits beim Laden der Seite kommt der Fehler...

      [Sat Oct 19 22:53:39 2002] [error] [client 127.0.0.1] malformed header from script. Bad header=input buffer overflow, can't e: db2www.exe, referer: http://localhost/cgi-bin/db2www.exe/4451/4451_d_issos_gdb_gen.d2w/init_part

      1. Hallo Rouven,

        [Sat Oct 19 22:53:39 2002] [error] [client 127.0.0.1] malformed header from script. Bad header=input buffer overflow, can't e: db2www.exe, referer: http://localhost/cgi-bin/db2www.exe/4451/4451_d_issos_gdb_gen.d2w/init_part

        "Dein" Script ist schuld (db2www.exe) - das kann die POST-Datenmenge nicht verarbeiten und sendet einfach auf die Standardausgabe den Text "input buffer overflow". Nachdem das Script das als erstes geschickt hat (und sich dann vmtl. beendet hat), vor allem anderen Zeug, versucht der Apache das als Header zu interpretieren und schlägt fehl. Tja - beschwer' dich beim Autor von db2www.exe, theoretisch kannst Du 4 Gigabyte (sic!) an POST-Daten verschicken. (macht aber wenig Sinn)

        Grüße,

        Christian

        1. Hallo!

          Danke erst einmal.
          Das bestätigt natürlich meine schlimmste Befürchtung - Jemand eine Idee, wie man das austricksen kann?

          Meine einzige Idee ist im Moment wirklich nur die Datensätze einzeln zu lesen, einzeln zu posten, einzeln zu verarbeiten und beim nächsten Satz von vorne zu beginnen...

          1. Hallo Rouven,

            was wäre mit Dateidownload/Dateiupload?
            Also gute alte Batch-Verarbeitung...

            Grüße

            Tom

            1. Folgende Großkampflage:
              2 Server mit 2 Datenbanken und ein System, bei dem man von Server A nicht zu Datenbank B connecten kann.
              Datenbank A: 3000+ Datensätze, im Wesentlichen "Schlüssel"
              Datenbank B: ganz-ganz viele Sätze mit Daten, durch Schlüssel suchbar

              Ziel: Alle Sätze von A sollen mit den Daten aus B zusammen in eine .csv-Datei geschrieben werden.

              Nun kann ich leider nicht einfach eine Datei erstellen und auf dem Server B speichern - dat mag dat Betriebssystem wohl nicht, oder die Skriptsprache - nicht fragen, ist irgendwie seltsam...

              Daher dachte ich eigentlich, ich poste mir einfach mal eben schnell alle Schlüssel rüber nach B, nur da man ja bei IBM keine großen HEADER mag...