fehler bei überabe von Formularwerten im ie?
Jan
- php
Hallo zusammen,
ich habe ein problem mit $_POST inhalten beim internet explorer 6 in zusammmenspiel mit meinem Replayscript. (http://12monkeys.dyndns.org:85/index.php?section=replays)
Dazu ist noch zusagen, das es mit einer anderen ie Version (vor neuinstallation des systems) funktioniert hatte, mir aber zu ohren gekommen ist das andere auch dieses Problem haben.
Ich habe schon mit print_r überprüft ob die Formularinhalte and den kritischen Stellen übergeben werden, meineserachtens tun sie das auch, aber die praxis beweist das gegenteil.
Also konkret ist das Problem, das in meiner csv Datei dann leere "Zellen" stehen, also keine Werte übergeben wurden. Das ist schon komisch, da das ganze mit opera und firefox funktioniert.
Ein "POST" in die replaysektion sieht normalerweise so aus:
(Trennungsoperatoren sidn | § µ )
WERT§WERT§WERT§WERT§WERT§WERT§WERT§VARIABLEµVARIABLEµ§WERT§WERT|
einer der Fehlerhaften "POSTS" sieht so aus:
WERT§§§§§WERT§WERT§§|
Habt ihr irgendwie im entferntesten eine Ahnung woran das liegen kann? Meiner meinung nach spielt da eindutig der client browser eine rolle.
-------------------------------------------------------------------
Dann hab ich da noch eine Netzwerktechnische Frage. Nachdem ich mein System neu installiert habe (win2000), konnte ich einige Seiten nicht laden. Mein rechner bekommt sein Internet über einen anderen win2k rechner per ICS. Nach einigen Stunden rumprobieren hab ich rausgefunden, das ich einen MTU eintrag in der registry unter services/tcpip/adapter mit einem wert kleiner 1500 machen muss. Nun geht wieder alles, aber es gibt da ein bild das ich immernochnicht laden kann, weder im ie, firefox oder opera.
In wiefern wirkt sich die MTU aufs surfen aus? wie kann ich die passende MTU für meinen Client ermitteln?
Gruß,
Jan
hi,
ich habe ein problem mit $_POST inhalten beim internet explorer 6 in zusammmenspiel mit meinem Replayscript. (http://12monkeys.dyndns.org:85/index.php?section=replays)
<form action='http://blasc.planet-multiplayer.de'
Bist du sicher, dass du das Formularziel _so_ angeben willst?
Wenn du erstmal lokal testest - wieso sollen die Formdaten dann direkt ins www gehen.
Was mir noch kritischer erscheint - Angabe der Domain ohne abschließenden Slash.
Bei normalem GET-Request erfolgt da sofort ein Redirect auf den URL plus abschließenden Slash - ob das aber jeder Browser auch bei POST-Daten mitmacht, möchte ich bezweifeln.
Zu genauerer Betrachtung lädt dieses Quellcodemonster, in dem sich offenbar kein einziger Zeilenumbruch befindet, nicht ein.
In wiefern wirkt sich die MTU aufs surfen aus? wie kann ich die passende MTU für meinen Client ermitteln?
http://de.wikipedia.org/wiki/Maximum_Transmission_Unit
Es gibt Programme, die einen als günstig für das jeweilige System angesehenen Wert setzen.
"Von Hand" geht's auch, über die Registry.
gruß,
wahsaga
echo $begrüßung;
<form action='http://blasc.planet-multiplayer.de'
Was mir noch kritischer erscheint - Angabe der Domain ohne abschließenden Slash.
Bei normalem GET-Request erfolgt da sofort ein Redirect auf den URL plus abschließenden Slash - ob das aber jeder Browser auch bei POST-Daten mitmacht, möchte ich bezweifeln.
Es gibt hier keinen Redirect, da der Request "POST HTTP/1.1" auf einen Server nicht statthaft ist und die Browser von sich aus "POST / HTTP/1.1" draus machen.
echo "$verabschiedung $name";
Hi,
Bist du sicher, dass du das Formularziel _so_ angeben willst?
das ist IMHO ein eher untergeordnetes Problem. Man betrachte mal das Ausmaß der Invalidität des Codes - aber vorher bitte hinsetzen!
Was mir noch kritischer erscheint - Angabe der Domain ohne abschließenden Slash.
Bei normalem GET-Request erfolgt da sofort ein Redirect auf den URL plus abschließenden Slash
Nope. Das Hinzufügen des Slashes ist eine Normalisierung (Kanonisierung), die der Client zunächst machen _muss_, weil er sonst den Request gar nicht absetzen kann[1]. Spätestens in Anbetracht der Tatsache, dass der IE 7 < RC1 Probleme mit nicht-kanonisierten URLs hat stellt sich aber die Frage, warum man dem Client diese Arbeit auferlegen will, anstatt gleich vernünftige URLs zu vermitteln.
Zu genauerer Betrachtung lädt dieses Quellcodemonster, in dem sich offenbar kein einziger Zeilenumbruch befindet, nicht ein.
Auch mit Zeilenumbrüchen sollte man sich in den Code nicht unbedingt vertiefen. Er ist so grauenhaft kaputt, dass sich eine Reparatur schwerlich lohnt. Mein Rat: Nutze den Code als Testgelände für die neuesten Sprengstoffe, und baue ihn anschließend von Null beginnend neu auf.
Cheatah
[1] "GET HTTP/1.1" ist keine wirklich sinnbehaftete Requestzeile ;-)
Äh,
[1] "GET HTTP/1.1" ist keine wirklich sinnbehaftete Requestzeile ;-)
und "POST HTTP/1.1" natürlich auch nicht. Danke, dedlfix.
Cheatah