nicht angemeldet
Henry
Gunnar Bittersmann
dedlfix
dedlfix
Gunnar Bittersmann
dedlfix
Hallo,
gerade fand ich bei eienr Fehlersuche etwas Unerwartetes. Vor vielen Jahren war hier mal die Thematik, ob man im Formular, genauer in der action-Angabe auch Werte mit einfügen darf. Der Tenor damals (finde das hier leider nicht mehr auf die Schnelle) war, dass das keine Problem wäre. War es auch nicht damals, mittlerweile ist es aber so, dass die Server/Browser sich anscheinend entscheiden die Parameter zu ignorieren.
Matthias Apsel<form action="xy.php?a=1&b=2"> führt nur zu xy.php
Ist das bekannt und seit wann hat sich das geändert oder habe ich das falsch in der Erinnerung?
Gruss
Henry
@@Henry
<form action="xy.php?a=1&b=2">
BTW, & ist in HTML ein Sonderzeichen und sollte escapet werden:
<form action="xy.php?a=1&b=2">
Es könnte zu unerwarteten Effekten kommen, wenn der Name des Parameters mit dem Bezeichner einer Zeichenentity übereinstimmt.
LLAP 🖖
Es könnte zu unerwarteten Effekten kommen, wenn der Name des Parameters mit dem Bezeichner einer Zeichenentity übereinstimmt.
Um das zu vermeiden gibt es die Pozentkodierung. MFG
Tach!
Es könnte zu unerwarteten Effekten kommen, wenn der Name des Parameters mit dem Bezeichner einer Zeichenentity übereinstimmt.
Um das zu vermeiden gibt es die Pozentkodierung.
Nicht in diesem HTML-Kontext, da ist & die richtige Kodierung für ein &.
dedlfix.
Tach!
Es könnte zu unerwarteten Effekten kommen, wenn der Name des Parameters mit dem Bezeichner einer Zeichenentity übereinstimmt.
Um das zu vermeiden gibt es die Pozentkodierung.
Nicht in diesem HTML-Kontext, da ist
&die richtige Kodierung für ein&.
In diesem Kontext ist das Ampersand kein Parameter! Und muss im Übrigen auch nicht als Entity notiert werden. MFG
Tach!
Es könnte zu unerwarteten Effekten kommen, wenn der Name des Parameters mit dem Bezeichner einer Zeichenentity übereinstimmt.
Um das zu vermeiden gibt es die Pozentkodierung.
Nicht in diesem HTML-Kontext, da ist
&die richtige Kodierung für ein&.In diesem Kontext ist das Ampersand kein Parameter!
Es ist kein Bestandteil von Key oder Value, deswegen muss es auch nicht für diesen Kontext maskiert werden. Aber für HTML sollte es maskiert sein.
<form action="test4.php?a=42%26b=23" method="post">
<input type="submit">
</form>
<form action="test4.php?a=42&b=23" method="post">
<input type="submit">
</form>
<pre>
<?php
print_r($_GET);
Schickst du das erste Formular ab, bekommst du
Array
(
[a] => 42&b=23
)
beim zweiten hingegen
Array
(
[a] => 42
[b] => 23
)
dedlfix.
Relevant und verbindlich für die Praxis war ist und bleibt für mich letztendlich das, was der Validator für richtig befindet. MFG
@@pl
Relevant und verbindlich für die Praxis war ist und bleibt für mich letztendlich das, was der Validator für richtig befindet. MFG
Relevant und verbindlich für die Praxis war, ist und bleibt, was rauskommen soll. Und was rauskommt, ist bei Prozent-Escaping was ganz anderes als bei HTML-Escaping; dedlfix hat die Unterschiede anschaulich dargestellt.
LLAP 🖖
Der Kontext für ein Ampersand im URL ist nicht HTML! Im Übrigen kann man diesen Delimiter auch anders benennen, was vielfach auch empfohlen wird.
MFG
Hallo pl,
Der Kontext für ein Ampersand im URL ist nicht HTML! Im Übrigen kann man diesen Delimiter auch anders benennen, was vielfach auch empfohlen wird.
Bevor es Teil der URL wird, ist ein ganz normaler Attributwert im HTML-Kontext.
Bis demnächst
Matthias
Tach!
gerade fand ich bei eienr Fehlersuche etwas Unerwartetes. Vor vielen Jahren war hier mal die Thematik, ob man im Formular, genauer in der action-Angabe auch Werte mit einfügen darf. Der Tenor damals (finde das hier leider nicht mehr auf die Schnelle) war, dass das keine Problem wäre.
Vermutlich war das eingeschränkt auf POST.
War es auch nicht damals, mittlerweile ist es aber so, dass die Server/Browser sich anscheinend entscheiden die Parameter zu ignorieren.
Parameter bei GET bilden sich aus den Formularwerten. Und Hidden-Inputs existieren. Hat man auch damals™ schon für zusätzliche, feststehende Werte verwendet.
Ist das bekannt und seit wann hat sich das geändert oder habe ich das falsch in der Erinnerung?
Die HTML-4.01-Spec ist da noch etwas ungenau formuliert. HTML5 hat ja meist nichts neues an den grundlegenden Dingen erfunden, sondern sie nur genauer spezifiziert. Dort steht, dass der Query-Teil der geparsten URL mit den den serialisierten Formularwerten gesetzt wird, nicht zusammengemischt.
dedlfix.
Nach dem MVC-Entwurfsmuster ist das action-Attribut ohnehin überflüssig, weil der URL derselbe ist. Zumal dessen alle Attribute im <form>-Element optional sind.
MFG
Lieber pl,
Nach dem MVC-Entwurfsmuster ist das action-Attribut ohnehin überflüssig
HTML hat nichts mit MVC zu tun. Dein Einwand liest sich für mich wie "aber denke doch einer an die Kinder!".
Liebe Grüße
Felix Riesterer
Nicht empfehlenswert. Soll das Submit per JS gehandelt werden, das <form>-action-Attribute (und alle anderen auch) ist für ein über dem <form> erstelltes FormData-Objekt uninteressant.
MFG
Anstatt ein action Attribut mit QUERY_STRING zu setzen für Formulare die mit POST rausgehen sollen, ist auch möglich, das Formular über eine Seite mit QUERY_STRING aufzurufen. Also bspw. zeigt der URL /?form=kunde ein Formular zum Editieren der Kundendaten.
Ein action Attribute wird nicht gesetzt und bei einem POST geht der Request an o.g. URL mit QUERY_STRING.
MFG
<form action="xy.php?a=1&b=2"><!-- führt nur zu xy.php -->Ist das bekannt und seit wann hat sich das geändert oder habe ich das falsch in der Erinnerung?
Mir deucht, das war schon immer so. Ich jedenfalls "verbaue" in solchen Fällen als "action" die xy.php und die Name/Wert Paare (hier das zusätzlich fehlerhafte) "a=1&b=2" als versteckte Inputs.
<form action="xy.php?a=1&b=2"><!-- führt nur zu xy.php -->Ist das bekannt und seit wann hat sich das geändert oder habe ich das falsch in der Erinnerung?
Mir deucht, das war schon immer so. Ich jedenfalls "verbaue" in solchen Fällen als "action" die xy.php und die Name/Wert Paare (hier das zusätzlich fehlerhafte) "a=1&b=2" als versteckte Inputs.
Ist ist nicht fehlerhaft. Bei einem POST geht der Request genau dahin. MFG