Vollständige Übertragung eines Formulars sicherstellen

[Diesmal lieber anonym...]

Liebe Forumsmitglieder,

diesmal poste ich ausnahmsweise mal ohne Namen, da ich das Problem nicht ganz so öffentlich rumposaunen möchte. Ich hoffe, ihr versteht das.

Folgendes Problem habe ich seit längerer Zeit: meinen Besuchern steht ein recht umfangreiches(!!!) Formular zur Verfügung, dessen Umfang sie aber selbst bestimmen. Dem Server ist (derzeit zumindest noch) zu jedem Zeitpunkt bekannt, wie das Formular des jeweiligen Nutzers aufgebaut ist: das Wachstum des Formulars erfolgt also serverseitig per PHP, nicht etwa clientseitig per JS.

Ein Beispielaufbau wäre etwa folgendes Formular:

<textarea>Mit Text</textarea>  
<input type="hidden" name="Bild_1">  
<textarea></textarea>  
<input type="hidden" name="Bild_2">  
<textarea>xxxxxxxxxxxxxxx  
xxxxxxxxxxxxxxx  
xxxxxxxxxxxxxxx  
xxxxxxxxxxxxxxx  
xxxxxxxxxxxxxxx</textarea>

Angenommen, ein User überträgt dieses Formular per Submit-Button (POST). Dann kommt das in 99% der Fälle auch vollständig an. Aber hin und wieder passiert es, dass das Formular unvollständig ankommt. Da fehlen dann
a) bspw. die letzten beiden Formularfelder
b) bspw. einfach mal der Inhalt eines solchen Feldes (das ist allerdings nur ein Verdacht.

Der Fall a) ist derzeit noch einfach zu erkennen, nämlich einfach per Vergleich mit dem erwarteten Aufbau des Formulars. Das ist natürlich nicht mehr möglich, wenn die User ihr Formular mal per JS erweitern können...
Den Fall b) kann ich aber gar nicht erkennen! Woher soll ich schließlich wissen, ob der User sein Textfeld nicht doch leeren wollte?

So, jetzt zu meiner Frage: erstmal ist mir überhaupt nicht klar, wie sowas überhaupt passieren kann? Kann das an instabilen Internetverbindungen liegen? Leider ist es sehr schwer zu testen, denn ich weiß nicht, wie ich den Fehler provozieren kann :-(

Und wie könnte ich effektiv dagegen vorgehen? Eine Variante wäre vielleicht, beim Submitten des Formulars per JavaScript ein Prüffeld anzulegen, mit dem das gesamte Formular abgeglichen werden kann (z.B. die Länge jedes Feldes).

Ich bin gespannt auf eure Meinung,
A....

[hotti]

moin,

Und wie könnte ich effektiv dagegen vorgehen? Eine Variante wäre vielleicht, beim Submitten des Formulars per JavaScript ein Prüffeld anzulegen, mit dem das gesamte Formular abgeglichen werden kann (z.B. die Länge jedes Feldes).

Das macht der Browser, der UserAgent. Der UA ermittelt für einen POST die Länge des Message-Body. An Deiner Stelle würde ich mal prüfen, ob der UA das richtig macht, prüfe also den HTTP-Header vom Request, ob Content-Length richtig übertragen wird.

Serverseitig findest Du diesen Header in der Umgebungs-Variablen CONTENT_LENGTH (Zum Gegenprüfen).

Meine Erwartungshaltung: Es ist nicht damit zu rechnen, dass der UA den Wert Content-Length falsch ermittelt, denn dann würden das ja alle Browser nicht richtig machen (prüfen!). Ich behaupte, dass der Fehler woanders liegt, z.B. in der Anwendung (Script) auf dem Server.

Hotti

[johny7]

Moin allerseits,

wenn wir schon bei Problemen mit Formularen sind:
Ich habe in letzter Zeit oft das Problem (vorrangig hier bei selfhtml), dass nach dem Abschicken des ausgefüllten Formulars dasselbe Formular wieder auftaucht - allerdings leer...
Ich habe es mir nun zur Gewohnheit gemacht, den Text in die Zwischenablage zu kopieren, bevor ich das Formular abschicke. Manchmal funktioniert es nämlich, in der History zurück zu gehen. Dann stehen die Inhalte noch alle da. Manchmal allerdings hilft auch das nicht. Wie gesagt, besonders häufig passiert das hier im Forum.
Liegt das evtl. an meiner schlechten Internetverbindung?

Grüße, JN

[Diesmal lieber anonym...]

Hallo johny7,

Ich behaupte, dass der Fehler woanders liegt, z.B. in der Anwendung (Script) auf dem Server.

Ich ja eigentlich auch! Allerdings habe ich das schon so reichlich durchgeprüft, dass ich nicht wüsste, wo da noch ein Fehler sein sollte. Zugegebenermassen, die Logik reichlich komplex, was natürlich für einen versteckten Fehler spricht.

Andererseits berichten meine Nutzer ziemlich übereinstimmend davon, dass sie zum Zeitpunkt des Fehlers eine richtig üble Internetverbindung hatten (wir sprechen hier von Dritte-Welt-Ländern). Das wiederrum spricht dafür, dass die Probleme irgendwo anders liegen.

Das macht der Browser, der UserAgent. Der UA ermittelt für einen POST die Länge des Message-Body. An Deiner Stelle würde ich mal prüfen, ob der UA das richtig macht, prüfe also den HTTP-Header vom Request, ob Content-Length richtig übertragen wird.

Ja, das werde ich mal probieren. Muss ich dann ja einfach nur für alle Anfragen mitloggen. Im Augenblick ist das aber erstmal zweitrangig, weil ich das ganze Formularzeug gerade komplett überarbeite. Das Logging bau ich dann zum Schluss ein.
Vorerst werde ich aber wohl tatsächlich mal ein Hidden-Feld per JS befüllen und auf die Art bspw. eine Art Checksum mitschicken. Soz. als Doppelcheck...

A....

[Diesmal lieber anonym...]

Ein weiterer Zusammenhang: häufig höre ich auch, die User hätten versucht, über ihre kriechlahme Verbindung auch große Fotos (>4MB) hochzuladen. Eventuell kann es ja zu Fehlern führen, wenn in einem solchen Fall (bei dem man eigentlich ja 10 Minuten warten müsste) der Vorgang abgebrochen wird?

A...

[hotti]

Ein weiterer Zusammenhang: häufig höre ich auch, die User hätten versucht, über ihre kriechlahme Verbindung auch große Fotos (>4MB) hochzuladen. Eventuell kann es ja zu Fehlern führen, wenn in einem solchen Fall (bei dem man eigentlich ja 10 Minuten warten müsste) der Vorgang abgebrochen wird?

Der CGI-Prozess wird nicht abgebrochen, solange ein POST aus STDIN gelesen wird und solange unter dem STDIN ein bestehendes Socket liegt, ein Socket ist das Handle was auf TCP aufsetzt.

Es kann jedoch sein, dass der Webserver nicht solange wartet, bis der CGI-Prozess zuende ist. Lt. Protokoll HTTP wirds jedoch auch in diesem Fall eine Response geben und der Webserver dann in FIN sendet (Connection: close) und das Socket wird geschlossen.

Hierzu schnappe Dir die üblichen Tools um sowas nachzustellen mit tcpdump, pcap, wireshark, ethereal etc.

Hotti