Formulare verlieren Inhalt auf dem Weg zum Server

[Utz]

Hi zusammen,

ab und an erlebe ich in seit einiger Zeit einen Fehler, auf den ich mir nicht so recht einen Reim machen kann.

Ich habe folgende "Konstruktion" - ein Formular (teils generiert, teils hartkodiert auf einer ASP-Seite), das an eine weitere ASP-Seite geschickt und dort verarbeitet wird - ganz simpel eigentlich.

In etwa 1% der Fälle geht jedoch die Übertragung der Formulardaten schief - das Formular wird anscheinend(?) bereits ohne Inhalt abgeschickt (obwohl belegte hidden-Felder hartkodiert sind, das also eigentlich gar nicht sein kann).

Netscape 4.x schickt das Formular anscheinend gar nicht ab und meldet "Document Contains No Data" - IE schickt es raus, da kann ich den Fehler behandeln (und daher auch die Zahl 1%). Beides hab ich selber aber noch nie gesehen, nur berichtet bekommen.

Ziemlich gut nachvollziehen kann ich den Fehler mit Opera 5, da geht's etwa bei 10% der Fälle schief.

Jetzt hab ich aber so rein gar keine Ahnung, was denn da in die Hose geht (ich denke: am ehesten was beim Verpacken der Formulardaten in HTTP resp. TCP/IP-Pakete?) und vor allem: was ich dagegen tun kann.

Kennt jemand solche Probleme und hat nen Tipp, wo ich suchen bzw. was ich dagegen unternehmen könnte? (Ach ja: Server läuft mit IIS 4)

Danke im Voraus und Grüße,

Utz

[n.d. parker]

Hi Utz,

Netscape 4.x schickt das Formular anscheinend gar nicht ab und meldet "Document Contains No Data" - IE schickt es raus, da kann ich den Fehler behandeln

das hat mit dem Formular nichts zu tun. Diese Meldung kommt, wenn vom Server ein Content-type gesendet wird, aber kein Inhalt.

(Beispiel: http://www.o3media.de/cgi-local/stuff/empty.pl, ist folgendes Script:)

=== cut ===
#!/usr/bin/perl

print "Content-type: text/html\n\n";

the end

=== cut ===

Ziemlich gut nachvollziehen kann ich den Fehler mit Opera 5, da geht's etwa bei 10% der Fälle schief.
Jetzt hab ich aber so rein gar keine Ahnung, was denn da in die Hose geht (ich denke: am ehesten was beim Verpacken der Formulardaten in HTTP resp. TCP/IP-Pakete?) und vor allem: was ich dagegen tun kann.

irgendwie riecht das nach einem Servertimeout - ist der Server stark belastet?
oder der Timeout vielleicht zu niedrig angesetzt?

hmm, koennte bei ner besonders schwachen anbindung auch ein browsertimeout sein...

HTH,

Viele Gruesse,

n.d.p.

[Utz]

Hi n.d.,

irgendwie riecht das nach einem Servertimeout - ist der Server stark belastet?
oder der Timeout vielleicht zu niedrig angesetzt?

hmm, koennte bei ner besonders schwachen anbindung auch ein browsertimeout sein...

Hm - laut Logfiles sieht es nicht so aus, als ginge es mit besonders hoher Belastung einher. Hab auch mal ne "Belastungstest" gemacht (sofern das per Hand überhaupt geht), parallel mit Netscape, IE und Opera, mit dem Ergebnis: keine Probleme mit IE und Netscape, aber etwa 10% Fehler bei Opera - kann natürlich aber auch Zufall sein...

Grüße,

Utz

[Michael Schröpl]

Hallo Utz,

Hm - laut Logfiles sieht es nicht so aus, als ginge es mit besonders hoher Belastung einher. Hab auch mal ne "Belastungstest" gemacht (sofern das per Hand überhaupt geht), parallel mit Netscape, IE und Opera, mit dem Ergebnis: keine Probleme mit IE und Netscape, aber etwa 10% Fehler bei Opera - kann natürlich aber auch Zufall sein ...

mein "Kandidat" für diesen Effekt wäre ein Programmfehler in der Server-Anwendung (ähnlich wie weiland der "Forums-Geist").
Dieser *könnte* eventuell die Ursache haben, daß irgendwelche Opera-spezifischen Dinge nicht korrekt ausgewertet werden, was dann die 10% erklären würde.

Fakt ist, daß die Formular-Daten auf dem Server ankommen - dies könntest Du dadurch verifizieren, daß Du Deine Server-Anwendung um eine Protokollfunktion erweiterst, bzw. im Webserver-Log nach den gescheiterten Aufrufen suchst. Die Parameter stecken ja normalerweise im URL (wenn Du "GET" verwendest).
Das ist überhaupt eine nützliche Methode: Bei Deiner bidirektionalen Kommunikation funktioniert irgendwas nicht - also zuallererst einmal herausfinden, auf welcher der beiden Kommunikationsstrecken der Fehler wirklich auftritt.

Deine Server-Anwendung gibt (wie n.d. beschrieben hat) den Content-type-Header aus und dann ggf. nichts mehr.
Es könnte also sein, daß sie entweder einfach abgestürzt ist (aber keinen Error500 ausgelöst hat, weil mit Returncode 0 beendet) oder irgendwas logisch falsch macht (z. B. eine zentrale "if"-Weiche falsch durchläuft und mangelhafte Fehlerbehandlung).

Um so etwas zu finden, hilft nur: Diagnosemöglichkeiten auf Maximum schalten.
Insbesondere solltest Du versuchen, die Parameterwerte der gescheiterten Aufrufe zu bestimmen, um zu prüfen, ob sich diese von denjenigen der erfolgreichen Aufrufe irgendwie unterscheiden.
Außerdem sollte Deine Server-Anwendung eine Art "Trace-Modus" haben, damit Du protokollieren kannst, wie weit sie gekommen ist. (Im Idealfall läßt man diesen Trace-Modus sogar in der produktiven Version drin und steuert ihn über ein Trace-Flag, d. h. einen dafür reservierten zusätzlichen CGI-Parameter im Aufruf-URL.)

Viele Grüße
      Michael

[Utz]

Hi Michael,

mein "Kandidat" für diesen Effekt wäre ein Programmfehler in der Server-Anwendung (ähnlich wie weiland der "Forums-Geist").

Dann ist ja zumindest geklärt, wo der geblieben ist *g*

Fakt ist, daß die Formular-Daten auf dem Server ankommen - dies könntest Du dadurch verifizieren, daß Du Deine Server-Anwendung um eine Protokollfunktion erweiterst, bzw. im Webserver-Log nach den gescheiterten Aufrufen suchst. Die Parameter stecken ja normalerweise im URL (wenn Du "GET" verwendest).

Bisher verwende ich POST, was die Sache aber nicht wirklich verkompliziert.

Vielleicht beschreibe ich am Besten mal, was die ASP-Seite macht, bevor sie aus der Kurve fliegt.

1. Einige Session-Variablen werden angelegt, jeweils leer.
2. Die Session-Variablen werden mit dem Inhalt des Formulars gefüllt.
3. Es wird geprüft, ob in der Session-Variable, die durch das hartkodierte Hidden-Feld gefüllt werden müsste, ein Wert steht - wenn nicht, gibt's nen Redirect auf ne Error-Seite, aus die Maus.

Netscape kommt wie gesagt schon gar nicht bis zum Redirect - es gibt keinen einzigen Eintrag in den Logfiles, dass die Error-Seite durch einen Netscape aufgerufen würde.

Deine Server-Anwendung gibt (wie n.d. beschrieben hat) den Content-type-Header aus und dann ggf. nichts mehr.

Hmmmm...da dämmert mir ne Idee...an der Stelle gibt der Server bereits nen Content-type-Header aus? Sollte er nicht...und schon gar nicht text/html - möglicherweise spinnt da einfach die ASP-Engine (der Geist! *g*), das könnte man ja in Griff kriegen, indem die http-response einfach bis nach dem Abarbeiten der Seite gepuffert wird. Das werde ich mal testen.

Grüße,

Utz

[Michael Schröpl]

Hallo Utz,

Hmmmm...da dämmert mir ne Idee...an der Stelle gibt der Server bereits nen Content-type-Header aus? Sollte er nicht...und schon gar nicht text/html - möglicherweise spinnt da einfach die ASP-Engine (der Geist! *g*), das könnte man ja in Griff kriegen, indem die http-response einfach bis nach dem Abarbeiten der Seite gepuffert wird. Das werde ich mal testen.

Mir kam gerade auch noch eine: Du verwendest einen M$-Server (IIS4).
Könnte es sein, daß der (anders als der Apache) selbst einen fehlenden HTTP-Header generiert, so daß Du anhand des Headers gar nicht feststellen kannst, wer ihn erzeugt hat?

Bau doch mal Ausgaben von HTML-Kommentaren in Dein ASP-Skript ein, dann kannst Du mit "view-source:" nachvollziehen, was das Skript alles getan hat, kannst Werte lokaler Variablen protokollieren usw. - und vor jeder solchen Ausgabe ein "if ($debug)" oder etwas Ähnliches, damit Du sie ggf. durch Ändern einer globalen Konstante ein- und ausschalten kannst (wenn schon nicht durch einen URL-Parameter).

Viele Grüße
      Michael

[Utz]

Hi Michael,

Mir kam gerade auch noch eine: Du verwendest einen M$-Server (IIS4).
Könnte es sein, daß der (anders als der Apache) selbst einen fehlenden HTTP-Header generiert, so daß Du anhand des Headers gar nicht feststellen kannst, wer ihn erzeugt hat?

Das Teil generiert eigentlich - sofern ich das richtig verstanden habe - dann einen HTTP-Header, wenn entweder a) eine response-Anweisung im ASP-(VB-Script-)Code steht, oder b) sofern HTML-Elemente auftauchen, die er intern wohl als response.write behandelt. Insofern dürfte er also eigentlich an der fraglichen Stelle noch keinen Header schreiben. _Eigentlich_ - aber Deine und n.d.s Interpretation der NS-Fehlermeldung legt ja nahe, dass ers eben doch macht.
Nach meinem Kenntnisstand kann man mit ASP-Bordmitteln den Header nicht komplett selber bestimmen (dafür leg ich aber nicht meinen Hund ins Feuer *g*), gibt aber bestimmt irgendwelche DLLs, die einem das ermöglichen - brächte mir aber auch nix, wenn das Teil tatsächlich wild anfängt, eigenmächtig Header zu erzeugen.

Meine augenblickliche Fehlerbehandlung ist ja eigentlich so eine von Dir vorgeschlagene Debug-Anweisung (wurde nur nachträglich zu ner Fehlerbehandlung aufgebohrt) - das kuriose dran ist halt wie gesagt, dass es schon passiert, _bevor_ das Skript irgendwas mit den Daten macht - es wird nur gecheckt, ob sie ankommen, und an der Stelle sind sie, wenn der Fehler auftritt, halt (nicht mehr?) da. Was ich noch machen kann ist z.B., alle Variablen als Querystring an die URL der error-Seite dranzuhängen, dann würde ich sehen (anhand der Logfiles), ob der komplette Inhalt des Formulars geflöten geht, oder nur Teile davon.

Grüße,

Utz