nicht angemeldet
Der Martin
dedlfix
dedlfix
Der Martin
Der Martin
Der Martin
dedlfix
Hallo Kollegen,
Ich habe folgendes Problem. Auf einer Seite hat man die Möglichkeit eine Datei auszuwählen und weitere Input Felder auszufüllen und diese Informationen zusammen mit der Datei zum Server hochzuladen.
Dazu habe ich ein Form erstellt mit ENCTYPE="multipart/form-data" und method=post, welches bei einem Klick auf "Upload" submitted wird. Die Informationen aus den Input Feldern hänge ich encodiert an die URL.
Dies Funktioniert bis zu dieser Stelle auch wunderbar - Alle Daten kommen am Server an.
Problem ist nun folgendes. Wenn ich gleich nach dem Upload nocheinmal eine Datei auswählen und hochladen möchte, komme ich nur auf eine weiße Seite und es passiert überhaupt nichts mehr. Das gleiche Verhalten lässt sich bei einem Klick auf einen Link beobachten. Das Problem tritt nur nach dem 1. submit auf.
Wo ist das Problem? Ich habe das Gefühl, dass nach dem 1. Upload irgendwie der "Kontext" verlassen wird und der Browser nicht mehr weiß wohin er das Form submitten soll.
viele Grüße
Lunatik
Hi,
Ich habe folgendes Problem. Auf einer Seite hat man die Möglichkeit eine Datei auszuwählen und weitere Input Felder auszufüllen und diese Informationen zusammen mit der Datei zum Server hochzuladen.
schön, und wohin geht die Antwort des formular-auswertenden Scripts?
Dazu habe ich ein Form erstellt mit ENCTYPE="multipart/form-data" und method=post, welches bei einem Klick auf "Upload" submitted wird. Die Informationen aus den Input Feldern hänge ich encodiert an die URL.
Auch 'ne Möglichkeit ...
Problem ist nun folgendes. Wenn ich gleich nach dem Upload nocheinmal eine Datei auswählen und hochladen möchte, ...
Äh, Moment: Wie? Die Seite mit dem Formular ist doch nun weg. Normalerweise. Es sei denn, dein serverseitiges Script sendet als Antwort einen Status 204 (No Content) oder wieder das gleiche Formular.
Wo ist das Problem? Ich habe das Gefühl, dass nach dem 1. Upload irgendwie der "Kontext" verlassen wird und der Browser nicht mehr weiß wohin er das Form submitten soll.
Zeig die Konstruktion mal als Live-Beispiel, dann kann man besser nachvollziehen, was da abgeht.
Ciao,
Martin
Hi!
Wenn ich gleich nach dem Upload nocheinmal eine Datei auswählen und hochladen möchte, komme ich nur auf eine weiße Seite und es passiert überhaupt nichts mehr. Das gleiche Verhalten lässt sich bei einem Klick auf einen Link beobachten. Das Problem tritt nur nach dem 1. submit auf.
Wo ist das Problem? Ich habe das Gefühl, dass nach dem 1. Upload irgendwie der "Kontext" verlassen wird und der Browser nicht mehr weiß wohin er das Form submitten soll.
Gefühle helfen bei Technik selten. Schau nach, was los ist. Eine weiße Seite ist das Ergebnis der Quelltextinterpretation durch den Browser. Das ist aber erst der letzte Schritt in der Verarbeitungskette. Du hast deinen Post in HTML/XHTML einsortiert. Also vermutest du ein Problem damit, hast aber noch nicht mal in den HTML-Code geschaut, den der Browser bekommt? Oder warum sprichst du nur abstrakt von einer weißen Seite? Was zeigt die Quelltextansicht? Vermutlich nichts, aber manchmal versteckt sich auch eine Fehlermeldung darin. Nächster Schritt ist das Auswerten des HTTP-Verkehrs. Zum Beispiel geht das mit der livehttpheaders-Extension vom Firefox. Besonders der Statuscode ist interessant. Noch ein Schritt rückwärts ist das Error-Log vom Webserver und von aufgerufenen Programmen (wie PHP) interessant. Wenn kein Error-Log konfiguriert ist, sollte das nachgeholt werden. Wenn das beim Hoster nicht geht, kannst du zumindest alle Einstellungen PHPs (ich nehme an, dass du das verwendest), die ein "error" im Namen haben kontrollieren, ob sie auf einen sinnvollen, möglichst geschwätzigen Wert eingestellt sind. (Nicht vergessen, in der Produktivumgebung alle öffentlichen Anzeigen wieder zu deaktivieren.) Spätestens in den Error-Logs sollte eine Information stehen, die eine deutlich zuverlässigere Spur zur Ursache ist als ein Gefühl.
Lo!
Gefühle helfen bei Technik selten. Schau nach, was los ist. Eine weiße Seite ist das Ergebnis der Quelltextinterpretation durch den Browser. Das ist aber erst der letzte Schritt in der Verarbeitungskette. Du hast deinen Post in HTML/XHTML einsortiert. Also vermutest du ein Problem damit, hast aber noch nicht mal in den HTML-Code geschaut, den der Browser bekommt? Oder warum sprichst du nur abstrakt von einer weißen Seite? Was zeigt die Quelltextansicht? Vermutlich nichts, aber manchmal versteckt sich auch eine Fehlermeldung darin.
Stimmt, hab ich überhaupt nicht dran gedacht. Im Firefox zeigt er mir in der Quelltextansicht michts an - also eine komplett leere Seite.
Nächster Schritt ist das Auswerten des HTTP-Verkehrs. Zum Beispiel geht das mit der livehttpheaders-Extension vom Firefox. Besonders der Statuscode ist interessant.
Danke für den Tipp! Hab ich sofort installiert.
Habe die Header jeweils für das 1. und das 2. (im Anschluss) Abschicken des Forms mitgeloggt.
Ich konnte zu Beginn der beiden logs feststellen, dass sich der Eintrag "Referer" voneinander unterscheidet.
Im 1. log (mitgeloggt beim 1. submit) steht unter Referer eine URL
Referer: http://127.0.0.1:8080/AnwendungsName/(...)/id=122:856
diese wird Serverseitig zusammengebaut und entspricht der Url der Seite von der aus ich das Formular absende.
Im 2. log (mitgeloggt beim 2. submit -> weiße Seite) steht im Referer die Anwendungs-URL mit der "Form-Action" meines Upload Forms am Ende:
Referer: http://127.0.0.1:8080/AnwendungsName/ActionUploadServ
Dies könnte doch schon das Problem sein?!
Diese Url steht auch gleich nach dem 1. Submit in der Adresszeile.
Noch ein Schritt rückwärts ist das Error-Log vom Webserver und von aufgerufenen Programmen (wie PHP) interessant. Wenn kein Error-Log konfiguriert ist, sollte das nachgeholt werden. Wenn das beim Hoster nicht geht, kannst du zumindest alle Einstellungen PHPs (ich nehme an, dass du das verwendest), die ein "error" im Namen haben kontrollieren, ob sie auf einen sinnvollen, möglichst geschwätzigen Wert eingestellt sind. (Nicht vergessen, in der Produktivumgebung alle öffentlichen Anzeigen wieder zu deaktivieren.) Spätestens in den Error-Logs sollte eine Information stehen, die eine deutlich zuverlässigere Spur zur Ursache ist als ein Gefühl.
Das werde ich mir anschauen. Als Webserver nutze ich Apache Tomcat.
Dieser leitet die Anfrage wiederum an eine Serveranwendung weiter die auf dem gleichen Rechner läuft.
viele Grüße
Lunatik
Hi!
Habe die Header jeweils für das 1. und das 2. (im Anschluss) Abschicken des Forms mitgeloggt.
Ich konnte zu Beginn der beiden logs feststellen, dass sich der Eintrag "Referer" voneinander unterscheidet.
Dies könnte doch schon das Problem sein?!
Der ist vermutlich unwichtig, wenn du ihn nicht auswertest. Und selbst dann kannst du nicht sicher sein, dass die Browser alle wahrheitsgemäß berichten. Wichtiger ist erstmal der Statuscode (erste Zeile der Antwort - 200, 404, 500, etc.)
Das werde ich mir anschauen. Als Webserver nutze ich Apache Tomcat.
Dieser leitet die Anfrage wiederum an eine Serveranwendung weiter die auf dem gleichen Rechner läuft.
Also dann das Error- und Action-Log vom Apachen, sowie die Logfiles der Anwendung befragen.
Lo!
Hi!
Habe die Header jeweils für das 1. und das 2. (im Anschluss) Abschicken des Forms mitgeloggt.
Ich konnte zu Beginn der beiden logs feststellen, dass sich der Eintrag "Referer" voneinander unterscheidet.
Dies könnte doch schon das Problem sein?!Der ist vermutlich unwichtig, wenn du ihn nicht auswertest. Und selbst dann kannst du nicht sicher sein, dass die Browser alle wahrheitsgemäß berichten. Wichtiger ist erstmal der Statuscode (erste Zeile der Antwort - 200, 404, 500, etc.)
Hier der Status vom 1. Submit:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html
Transfer-Encoding: chunked
Date: Fri, 07 Oct 2011 07:44:23 GMT
----------------------------------------------------------
Und vom 2. Submit:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Fri, 07 Oct 2011 07:51:02 GMT
----------------------------------------------------------
Nach dem 2. steht nichts mehr in der (Firefox) Log Datei.
Nach dem 1. stehen noch 6 Get Anfragen gefolgt von Requests im Log z.B.:
----------------------------------------------------------
http://127.0.0.1:8080/anwendungsName/images%5C%5Capp%5C%5Cnew.png
GET /anwendungsName/images%5C%5Capp%5C%5Cnew.png HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://127.0.0.1:8080/anwendungsName/ActionUploadServ
Cookie: xExt_Login=Ben123; janusExt_Language=deutsch; XSESSIONID=E241650B8EACC5C79DA286E446E58742
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Fri, 07 Oct 2011 07:44:23 GMT
Connection: close
----------------------------------------------------------
Das werde ich mir anschauen. Als Webserver nutze ich Apache Tomcat.
Dieser leitet die Anfrage wiederum an eine Serveranwendung weiter die auf dem gleichen Rechner läuft.Also dann das Error- und Action-Log vom Apachen, sowie die Logfiles der Anwendung befragen.
Lo!
Hallo,
Hier der Status vom 1. Submit:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html
Transfer-Encoding: chunked
Date: Fri, 07 Oct 2011 07:44:23 GMT
sieht einigermaßen anständig aus. Content-Length wäre noch "nice to have", ist aber weder vorgeschrieben noch unbedingt notwendig.
Und vom 2. Submit:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Fri, 07 Oct 2011 07:51:02 GMT
Ach? Kein Content-Type? Der *ist* aber AFAIK vorgeschrieben - auch wenn es bei Nutzdatenlänge 0 nicht wirklich sinnvoll ist, diesem "Nichts" noch einen Typ mitzugeben. Anyway, der Server sendet also tatsächlich eine "leere" Antwort. Wie lautete der Request dazu?
Nach dem 2. steht nichts mehr in der (Firefox) Log Datei.
Nee, warum auch - das leere Dokument spricht ja für sich. ;-)
Nach dem 1. stehen noch 6 Get Anfragen gefolgt von Requests im Log z.B.:
http://127.0.0.1:8080/anwendungsName/images%5C%5Capp%5C%5Cnew.png
Okay, Bilder und andere eingebundene Ressourcen. Warum da allerdings zweimal zwei Backslashes im Namen auftauchen, würde mich interessieren. Das gehört sich nicht.
Ciao,
Martin
Und vom 2. Submit:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Fri, 07 Oct 2011 07:51:02 GMTAch? Kein Content-Type? Der *ist* aber AFAIK vorgeschrieben - auch wenn es bei Nutzdatenlänge 0 nicht wirklich sinnvoll ist, diesem "Nichts" noch einen Typ mitzugeben. Anyway, der Server sendet also tatsächlich eine "leere" Antwort. Wie lautete der Request dazu?
Hier der Request dazu (2. submit, der auf leere/weiße Seite führt):
--------------
http://127.0.0.1:8080/anwendungsName/ActionUploadServ
POST /anwendungsName/ActionUploadServ HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://127.0.0.1:8080/anwendungsName/ActionUploadServ
Cookie: xExt_Login=Ben123; xExt_Language=deutsch; XSESSIONID=E241650B8EACC5C79DA286E446E58742
Content-Type: multipart/form-data; boundary=---------------------------265001916915724
Content-Length: 69438
--------------
Wie bereits erwähnt unterscheidet sich der Request vom 1. und 2. submit hier nur durch den Wert des Eintrages "Referer". Hier, beim Request des 2. submits, steht der Action-Wert des Formulars am Ende der Url.
Nach dem 1. stehen noch 6 Get Anfragen gefolgt von Requests im Log z.B.:
http://127.0.0.1:8080/anwendungsName/images%5C%5Capp%5C%5Cnew.png
Okay, Bilder und andere eingebundene Ressourcen. Warum da allerdings zweimal zwei Backslashes im Namen auftauchen, würde mich interessieren. Das gehört sich nicht.
stimmt, müssten normale slashes sein.
Ciao,
Martin
Vielen Dank für deine Hilfe!
Lunatik
Hallo,
Hier der Request dazu (2. submit, der auf leere/weiße Seite führt):
http://127.0.0.1:8080/anwendungsName/ActionUploadServ
[...]
sieht auf den ersten Blick auch unverdächtig aus. Aber hattest du nicht gesagt, du übergibst außer dem Datei-Upload weitere Daten als URL-Parameter? Davon sehe ich hier nichts.
Wie bereits erwähnt unterscheidet sich der Request vom 1. und 2. submit hier nur durch den Wert des Eintrages "Referer".
Und dem Request URI. Und möglicherweise den POST-Daten (aber das zu vergleichen wird mühsam).
Ciao,
Martin
Hallo,
Hier der Request dazu (2. submit, der auf leere/weiße Seite führt):
http://127.0.0.1:8080/anwendungsName/ActionUploadServ
[...]sieht auf den ersten Blick auch unverdächtig aus. Aber hattest du nicht gesagt, du übergibst außer dem Datei-Upload weitere Daten als URL-Parameter? Davon sehe ich hier nichts.
Wie bereits erwähnt unterscheidet sich der Request vom 1. und 2. submit hier nur durch den Wert des Eintrages "Referer".
Und dem Request URI. Und möglicherweise den POST-Daten (aber das zu vergleichen wird mühsam).
Ich frage mich warum der Content-type leer ist? Wenn ich im HTML-Quelltext nach dem 1. Submit nachschaue steht unter Content-type
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
also das gleiche wie vor dem submit. Wie kommt es nun zustande, dass bei 1. request was unter content-type eingetragen ist, beim 2. aber nicht?
Würde es was bringen den Content Type per Javascript neu zu setzen?
Jetzt bin ich noch verwirrter wie vorher :-|
Ciao,
Martin
Hi,
Ich frage mich warum der Content-type leer ist?
frag das deinen Server! ;-)
Wenn ich im HTML-Quelltext nach dem 1. Submit nachschaue steht unter Content-type
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
Das hat damit allerdings GAR NICHTS zu tun.
Würde es was bringen den Content Type per Javascript neu zu setzen?
Javascript?? Mach dir bitte nochmal das Zusammenspiel zwischen Server und Client klar. Wenn Javascript (beim Client) zum Zug kommt, ist bzgl. HTTP längst alles gelaufen.
Ciao,
Martin
Hi!
Wenn ich im HTML-Quelltext nach dem 1. Submit nachschaue steht unter Content-type
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
Das hat damit allerdings GAR NICHTS zu tun.
Wenn's noch ein bisschen mehr Erklärung sein darf: HTML ist ja nicht das einzige Format, das ein Webserver ausliefern kann. Der HTTP-Header namens Content-Type ist nach der Status-Information die wichtigste Angabe für den Empfänger und meines Wissens auch ein Pflicht-Element. Einen Dokumenttyp aus dem Inhalt herauszulesen, ist nur aufwendig und mitunter gar nicht eindeutig möglich.
Lo!
