Validator

[paierlep]

Hallo!

Ich bekomme seltsame Fehler beim Validator

Hier der Codeauszug aus einem XHTML 1.0 Strict Gerüst:

  
<form method="post" action="/cp/100808/admin/index.php?type=save&pageId=1">  
  <fieldset>  
    <textarea name="content" rows="5" cols="50">()</textarea>  
      <input type="submit" value="Speichern" style="display:none"/>  
  </fieldset>  
</form>  

Der Validator zeigt mir, dass bei "type=save&pageId=1" Das & falsch sein -> er will es maskiert (&) haben, was aber an dieser Stelle keinen Sinn macht...
Hat irgendwer eine Idee - bin inzwischen schon etwas ratlos???

grüße!

[Daniel unreg]

Hallo,

Der Validator zeigt mir, dass bei "type=save&pageId=1" Das & falsch sein -> er will es maskiert (&) haben, was aber an dieser Stelle keinen Sinn macht...

Wieso sollte das keinen Sinn machen? & sollte immer maskiert werden, ob nun im Fließtext oder als Bestandteil eines Verweises. Andernfalls riskierst du, dass der browser irgendwann das Formular an type=save[Sonderzeichen]=1 sendet, was nicht in deinem Interesse sein dürfte.

Gruß

[Beat]

Ich bekomme seltsame Fehler beim Validator
Hier der Codeauszug aus einem XHTML 1.0 Strict Gerüst:

<form method="post" action="/cp/100808/admin/index.php?type=save&pageId=1">
  <fieldset>
    <textarea name="content" rows="5" cols="50">()</textarea>
      <input type="submit" value="Speichern" style="display:none"/>
  </fieldset>
</form>

>   
> Der Validator zeigt mir, dass bei "type=save&pageId=1" Das & falsch sein -> er will es maskiert (&) haben, was aber an dieser Stelle keinen Sinn macht...  
  
Doch das macht durchaus Sinn, wie vom Vorredner schon bemerkt. Es muss & geschrieben werden.  
  
Für solche Fälle eignen sich übrigens  
  
~~~html
  
<input type="hidden" name="type" value="save" />  
<input type="hidden" name="pageId" value="1" />  

mfg Beat

[paierlep]

Guten Morgen!

Doch das macht durchaus Sinn, wie vom Vorredner schon bemerkt. Es muss &amp; geschrieben werden.

naja ich wollte eigentlich per $_GET diese beiden Werte an ein PHP Skript überliefern, pageId wird in dem Fall dynamisch erzeugt, daher wäre es kürzer einfach nur die Übergabeurl zu manipulieren...

Für solche Fälle eignen sich übrigens

<input type="hidden" name="type" value="save" />
<input type="hidden" name="pageId" value="1" />

  
Werde wahrscheinlich. wenns dann keine andere Möglichkeit gibt mit den hidden Feldern arbeiten...  
  
grüße!  

[Christoph Jeschke]

Für solche Fälle eignen sich übrigens

<input type="hidden" name="type" value="save" />
<input type="hidden" name="pageId" value="1" />

  
Das ist aber nicht äquivalent zu dem, was der OP erreichen wollte: Dieser wollte type und pageId als GET-Parameter übergeben, während die Textarea und der Submit-Button per POST übergeben werden.  
  
Er muss also auf jeden Fall das Ampersand durch dessen Entity ersetzen.  
  
Das W3C [empfiehlt](http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2) übrigens, statt des Ampersands das Semikolon zu verwenden.  
  
Gruß  
Christoph

[Beat]

Das W3C empfiehlt übrigens, statt des Ampersands das Semikolon zu verwenden.

Das kann mir jetzt echt den A.. runter, was das W*C zu Thema & sagt. Die haben es nämlich versäumt, für Formulare ein Attribut zu definieren, welches die Angabe eines frei wählbaren Datensatztrennzeichens erlaubt.

Dass ; Probleme vermeidet, steht ausser Zweifel.

mfg Beat

[Daniel unreg]

Hallo,

Das kann mir jetzt echt den A.. runter, was das W*C zu Thema & sagt. Die haben es nämlich versäumt, für Formulare ein Attribut zu definieren, welches die Angabe eines frei wählbaren Datensatztrennzeichens erlaubt.

Sowas kann nicht funktionieren. Wann und wie soll die serverseitige Software dieses Trennzeichen verarbeiten? Es müsste mitgesendet werden, aber dann wäre es schon wieder zu spät.

Welches Zeichen als Datensatztrennzeichen verarbeitet wird liegt an der serverseitig eingesetzen Software und zumindest bei PHP (und wenn die das können, dann können es alle anderen auch) kann es frei gewählt werden.

gruß

[Beat]

Hallo,

Das kann mir jetzt echt den A.. runter, was das W*C zu Thema & sagt. Die haben es nämlich versäumt, für Formulare ein Attribut zu definieren, welches die Angabe eines frei wählbaren Datensatztrennzeichens erlaubt.

Sowas kann nicht funktionieren. Wann und wie soll die serverseitige Software dieses Trennzeichen verarbeiten? Es müsste mitgesendet werden, aber dann wäre es schon wieder zu spät.

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.

Welches Zeichen als Datensatztrennzeichen verarbeitet wird liegt an der serverseitig eingesetzen Software und zumindest bei PHP (und wenn die das können, dann können es alle anderen auch) kann es frei gewählt werden.

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.

mfg Beat

[Daniel unreg]

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.

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.

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.

[Beat]

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&parameter2=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

[Daniel unreg]

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&parameter2=wert
zusammenbastelt?

Hier stellt sich aber das ursprüngliche Problem gar nicht erst, deswegen sehe ich keinen Sinn hier weiterzumachen.

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.

Das behaupte ich nicht. Ich kenne mich mit HTTP nun auch nicht so gut aus, aber hier wird POST, GET usw. definiert. Die Schuld an dem Problem trägt dann die Stelle, die & und ; ursprüglich für diesen Zweck eingeführt haben.

[Timo "God's Boss" Reitz]

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&parameter2=wert
zusammenbastelt?
Hier stellt sich aber das ursprüngliche Problem gar nicht erst, deswegen sehe ich keinen Sinn hier weiterzumachen.

Wieso nicht? Natürlich gibt es hier keine Probleme mit "&", der Browser erstellt ja die vollständige URL. Blöd ist es nur, wenn man beide Varianten in seiner Webpräsenz verwendet, d.h. Links mit Query-Strings und GET-Formulare, will man dann nämlich der W3C-Empfehlung folgen, ";" zu verwenden, hat man URLs mit "&" und welche mit ";". Irgendwie unschön und uneinheitlich.

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.
Das behaupte ich nicht. Ich kenne mich mit HTTP nun auch nicht so gut aus, aber hier wird POST, GET usw. definiert. Die Schuld an dem Problem trägt dann die Stelle, die & und ; ursprüglich für diesen Zweck eingeführt haben.

HTML 4.01: 17.13.4 Form content types ist es in diesem Fall. Es ist also tatsächlich nicht HTTP der "Übeltäter".

[Daniel unreg]

Blöd ist es nur, wenn man beide Varianten in seiner Webpräsenz verwendet, d.h. Links mit Query-Strings und GET-Formulare, will man dann nämlich der W3C-Empfehlung folgen, ";" zu verwenden, hat man URLs mit "&" und welche mit ";". Irgendwie unschön und uneinheitlich.

Mir stellt sich nur die Frage, warum man das überhaupt machen sollte. Wo liegt das Problem & zu maskieren bzw. welche teuflichen Resultate würde dies zur Folge haben?

[Timo "God's Boss" Reitz]

Sowas kann nicht funktionieren. Wann und wie soll die serverseitige Software dieses Trennzeichen verarbeiten? Es müsste mitgesendet werden, aber dann wäre es schon wieder zu spät.
Welches Zeichen als Datensatztrennzeichen verarbeitet wird liegt an der serverseitig eingesetzen Software und zumindest bei PHP (und wenn die das können, dann können es alle anderen auch) kann es frei gewählt werden.

Wenn ich ein GET-Formular baue, dann kann ich den Datentrenner nur leider nicht festlegen, es ist immer "&". Man kann also nicht gleichzeitig GET-Formulare verwenden und der W3C-Empfehlung folgen.

[Daniel unreg]

Wenn ich ein GET-Formular baue, dann kann ich den Datentrenner nur leider nicht festlegen, es ist immer "&". Man kann also nicht gleichzeitig GET-Formulare verwenden und der W3C-Empfehlung folgen.

Ok, aber wieso sollte dass nicht gleichzeitig möglich sein? Worin liegt das Problem, & als &amp; zu maskieren? Mir wären da keine Problemfälle bekannt.

[Timo "God's Boss" Reitz]

Wenn ich ein GET-Formular baue, dann kann ich den Datentrenner nur leider nicht festlegen, es ist immer "&". Man kann also nicht gleichzeitig GET-Formulare verwenden und der W3C-Empfehlung folgen.
Ok, aber wieso sollte dass nicht gleichzeitig möglich sein? Worin liegt das Problem, & als &amp; zu maskieren? Mir wären da keine Problemfälle bekannt.

Mit W3C-Empfehlung ist in diesem Fall gemeint, ";" als Datentrenner in der URL zu verwenden.

[Der Martin]

Hi,

Das kann mir jetzt echt den A.. runter, was das W*C zu Thema & sagt. Die haben es nämlich versäumt, für Formulare ein Attribut zu definieren, welches die Angabe eines frei wählbaren Datensatztrennzeichens erlaubt.

Sowas kann nicht funktionieren. Wann und wie soll die serverseitige Software dieses Trennzeichen verarbeiten? Es müsste mitgesendet werden, aber dann wäre es schon wieder zu spät.

die serverseitige Verarbeitung ist nicht das Problem. Das "Problem" ist vielmehr, dass beim Absenden eines Formulars die Verwendung von '&' als Trennzeichen in den Browsern fest codiert ist, der Webautor also gar keine Chance hat, stattdessen beispielsweise ';' zu verwenden.

Ciao,
 Martin