GET & POST-Gemisch nicht standardkonform?
iGEL
- html
Hallo!
Ich verwende in meinen Scripten recht häufig Formulare, die gleichzeitig per GET und per POST Daten übergeben sollen. Das sieht dann so aus:
<form action="script.php?a=einlesen&sa=uebernehmen" method="post">
<input name="lalala">
<input type="submit>
</form>
Nur musste ich feststellen, dass manchmal die GET-Daten einfach nicht übermittelt werden, auch in der Browserzeile tauchen die Angaben einfach nicht auf. Eine Regelmässigkeit dafür konnte ich nicht feststellen, ausser dass es immer die selben Stellen sind (Anderswo funktionieren sie in gleicher oder ähnlicher Form aber wunderbar).
Daher meine Frage: Ist das nicht standardkonform? Ich mache das ja nur, weil ich mir den ganzen Haufen <input type="hidden">-Tags sparen will, aber wenn es sein muss...
Danke schon mal,
iGEL
Hallo iGEL,
Ich verwende in meinen Scripten recht häufig Formulare, die gleichzeitig per GET und per POST Daten übergeben sollen. Das sieht dann so aus:
<form action="script.php?a=einlesen&sa=uebernehmen" method="post">
<input name="lalala">
<input type="submit>
</form>
Das mache ich auch bisweilen. PHP sortiert die Variablen im Query-String auch in $_GET ein, wenn das Formular per POST geschickt wird. Das ist die eigentliche Standardinkonformität, die ich dabei feststelle.
Grundsätzlich: Ein HTTP-Request *kann* garnicht aus mehr als einer Methode bestehen. Das heißt zwar, dass an das Form nicht gleichzeitig per POST und GET verschicken kann, heißt aber auch, dass im Query-String weiterhin alles an Parametern erlaubt ist, sofern der Server bereit ist, diese auch bei POST-Methoden auszuwerfen.
Nur musste ich feststellen, dass manchmal die GET-Daten einfach nicht übermittelt werden, auch in der Browserzeile tauchen die Angaben einfach nicht auf. Eine Regelmässigkeit dafür konnte ich nicht feststellen, ausser dass es immer die selben Stellen sind (Anderswo funktionieren sie in gleicher oder ähnlicher Form aber wunderbar).
Dazu kann ich nichts sagen. Versuch mal das Problem einzugrenzen:
Wann tritt das Problem auf (Server, Zeit, Methode, Eingabedaten, Serverseitige Sprache)?
Wann funktioniert es?
Grüße aus Barsinghausen,
Fabian
Moin!
Dazu kann ich nichts sagen. Versuch mal das Problem einzugrenzen:
Das ist nicht so einfach, echte Regelmässigkeiten habe ich noch nicht feststellen können.
Wann tritt das Problem auf (Server, Zeit, Methode, Eingabedaten, Serverseitige Sprache)?
Wann funktioniert es?
Besonders gerne tritt es auf, wenn ich ein Formular habe, das eigentlich selbst keine Eingabefelder übermittelt (Ich also das Formular zweckentfremdet als Link verwendet habe). Leider habe ich inzwischen die meisten Stellen beseitigt, wo es auftrat.
Ein solches Beispiel:
<form action="script.php?a=logout" method="post">
<input type="submit" value="Logout">
</form>
Bei Formularen mit Eingabedaten trat das Problem aber auch auf. Browser: "Sicherheitsloch mit Browserfunktionen 5.5" (Internet Explorer), ist hier in der Firma halt Standard.
Johannes
Hi,
GET und POST mixen geht eigentlich sehr gut (mal vom Roxen-Server ab V3 abgesehen) aber Dein Form-Befehl ist nicht richtig:
<form action="script.php?a=einlesen&sa=uebernehmen" ethod="post">
Das & Zeichen darf natürlich nicht durch & ersetzt werden, es ist ja keine HTML-Ausgabe, sondern der Feldtrenner im QueryString.
Stephan
http://www.w3solutions.de
Hi,
<form action="script.php?a=einlesen&sa=uebernehmen" ethod="post">
Das & Zeichen darf natürlich nicht durch & ersetzt werden, es ist ja keine HTML-Ausgabe, sondern der Feldtrenner im QueryString.
Es steht aber in eienr HTML-Datei und muss somit durch & ersetzt werden. Egal ob es in einem Atribut oder im "normalen" Text irgendwo steht.
wunderwarzenschwein
Moin!
Das & Zeichen darf natürlich nicht durch & ersetzt werden, es ist ja keine HTML-Ausgabe, sondern der Feldtrenner im QueryString.
Doch, das ist HTML-Standard und wird von allen Browsern umgewandelt. Zeitweise hat der w3c-HTML-Validator sogar bei nem einfachen & ne Fehlermeldung ausgespuckt, obwohl es natürlich auch zulässig ist. Seitdem hab ich mir angewöhnt, das & immer zu escapen.
Trotzdem danke für die Antwort. Ich glaube inzwischen, dass es ein Bug vom IE ist, wäre ja nicht der erste...
Johannes