ampersand-Übergabe an Google-Formular durch Mechanize

[Der Martin]

Hi,

Nur im HTML-Kontext wird & als & maskiert. Im URL-Kontext, der hier vermutlich vorliegt, wird & als %26 maskiert - aber nur, wenn es als Nutzzeichen gelten soll. Wenn es als Trennzeichen zwischen mehreren URL-Parametern dient, wird es im URL-Kontext gar nicht maskiert.
Sieht aber doch so aus. Oder könnte das in Mechanize beim "submit_form-Befehl" geschehen?

ich habe keine Ahnung von Perl und weiß daher nicht, was die einzelnen Komponenten für Magie einfließen lassen.

Wo liegt mein Denkfehler?
In der fehlerhaften Kontext-Betrachtung.
Kannst Du mir noch weiterhelfen?

Okay. Nehmen wir ein abstraktes Beispiel: Ich möchte die Ressource http://example.org/ aufrufen und ihr mehrere URL-Parameter übergeben. Also müsste der HTTP-Request lauten:

[1] http://example.org/?param1=value1&param2=value2&param3=value3

Das & wird also in diesem Kontext gar nicht maskiert, weil es beim Server in seiner Sonderbedeutung als Trennzeichen zwischen den URL-Parametern verstanden werden soll.
Nun soll param1 den Wert "copy&paste" haben (das sind die Kollegen von Smith&Wesson). Dieses & soll *nicht* die oben beschriebene Sonderbedeutung haben, sondern ist "wörtlich" gemeint und muss daher maskiert werden. Da wir im URL-Kontext sind, mit der URL-Codierung:

[2] http://example.org/?param1=copy%26paste&param2=value2&param3=value3

Im dritten Schritt wollen wir diesen Request als Link in einem HTML-Dokument notieren. In HTML muss das & maskiert werden, da es ansonsten eine Entity-Referenz oder NCR einleitet. Also muss & zu & werden:

[3] http://example.org/?param1=copy%26paste&param2=value2&param3=value3

Diese Maskierung macht der Browser bereits beim Interpretieren des HTML-Quellcodes rückgängig. Wenn der Link [3] angeklickt wird, entsteht daraus also wieder die URL-Notation [2].

Wenn du jetzt fälschlicherweise außerhalb des HTML-Kontexts ein & als & notierst und das so in den HTTP-Request einbringst, kommt der als [3] gezeigte String beim Server an. Dann würde ein serverseitiges Script zwar immer noch drei URL-Parameter erkennen, aber mit falschen Namen:

param1=copy%26paste
  amp;param2=value2
  amp;param3=value3

Eventuell hast du sogar Glück, und die serverseitige Scriptlogik ist so konfiguriert, dass sie alternativ auch ein Semikolon als Trennzeichen von URL-Parametern akzeptiert (wird oft empfohlen). Dann würde diese Logik fünf URL-Parameter erkennen, wobei zwei davon den gleichen Namen haben:

param1=copy%26paste
  amp
  param2=value2
  amp
  param3=value3

Da Scripte in der Regel per Namen auf die URL-Parameter zugreifen und nicht per numerischem Index, würde das sogar trotz des fehlerhaften Requests funktionieren. Richtig ist es dennoch nicht.

Ist es nun klarer? Wenn nicht, frage bitte konkret, weil ich nicht ahnen kann, wo sonst deine Verständnislücken sind.

So long,
 Martin