Falls es das Attribut gäbe, könnte es vom Formularersteller, der ja auch die auslesende Software ist, definiert werden. Nix wäre zu spät.
Es kann, wie gesagt, auch ohne Attribut, definiert werden.
Wo stehst du denn auf dem Schlauch?
Wenn ich ein Input Feld habe
<input type="text" name="parameter1" value="wert">
<input type="text" name="parameter2" value="wert">
Mit welchem Parameter willst du dann bestimmen, dass der Browser NICHT
?parameter1=wert¶meter2=wert
zusammenbastelt?
Nein, es liegt nicht bei der Software. Diese ist heute dazu verdammt & zu verwenden, wenn sie mit POST Daten arbeiten will, die aus Formularen erzeugt werden. Sie kann allenfalls bei Query Strings sich flexibler verhalten, und muss dann zweigleisig auslesen.
Ich sehe da keinen nennenswerten Unterschied.
Für dich als eventueller PHP Endverbraucher wohl nicht...
Es stellt sich mir auchn gleich noch die Frage, ob man das W3C hier beschuldigen kann. Das zugrundeliegende Problem scheint ja dann doch in der HTTP-Spezifikation zu liegen.
Wo erzwingt diese, dass content strukturiert als parameter=wert '&' auschliesslich zu übertragen sei. Die innere Struktur von content geht HTTP gar nichts an. Content beginnt als message body nach einem zusätzlichen CRLF, welches die Request Header Section abschliesst.
Der Nachweis zum Gegenteil liegt bei dir.
Dazu darfst du mir interpretieren:
Request Aufbau
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5
Message Body
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3
Entity Body
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2
method POST
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
etc...
mfg Beat
Woran ich arbeite:
X-Torah
Plädoyer für eine alte Mystik
und Vers-Einteilung
in der Torah und der Apokalypse
Beat Stoecklin 2008
/|
<°)))o>< / | /|
---- _|___/ | ><o(((°>
OvVVvO __ | ><o(((°>
<°)))o>< /v v\/ |
<°)))o>< ^ ^/_/_ ><o(((°>
^^^^/___/
><o(((°> ---- ><o(((°>
<°)))o>< ><o(((°>o