param() mit Semikolon wird nicht eingelesen
Martin Asal
folgendes HTML-Formular:
<form action="foo.pl" method="POST">
<textarea name="bar">
bla; bla
</textarea>
</form>
wird von foo.pl wie folgt eingelesen:
use CGI qw(:cgi);
my $bar = param("bar");
Funktioniert prima. Nun möchte ich aber foo.pl _von einem anderen
Perlscript_ aus ansprechen:
my $url = "foo.pl";
my $val = "bar=bla; bla";
my $ua = new LWP::UserAgent;
my $head = new HTTP::Headers;
my $req = new HTTP::Request("POST", $url, $head, $val);
my $response = $ua->request($req);
Genau hier bekomme ich aber ein Problem: Sobald der Dateninhalt ($val)
ein Semikolon enthält, wird er von foo.pl nur bis zu dem Zeichen davor
eingelesen (Über STDIN kommt aber definitiv alles rein).
Was muss ich tun, um den gesamten Dateninhalt einlesen zu können?
danke schon mal vorab
Martin
Wolf Behrenhoff
> Nun möchte ich aber foo.pl _von einem anderen
> Perlscript_ aus ansprechen:
>
> my $url = "foo.pl";
> my $val = "bar=bla; bla";
> my $ua = new LWP::UserAgent;
> my $head = new HTTP::Headers;
> my $req = new HTTP::Request("POST", $url, $head, $val);
> my $response = $ua->request($req);
>
> Genau hier bekomme ich aber ein Problem: Sobald der Dateninhalt ($val)
> ein Semikolon enthält, wird er von foo.pl nur bis zu dem Zeichen davor
> eingelesen (Über STDIN kommt aber definitiv alles rein).
>
> Was muss ich tun, um den gesamten Dateninhalt einlesen zu können?
Richtig kodieren!
my $val = "bar=bla%3B+bla";
Als Aufgabe sei dir überlassen, die richtige Quote-Funktion dafür zu
suchen (perldoc URI::Escape könnte helfen).
- Wolf
Martin Asal
> (perldoc URI::Escape könnte helfen).
Jawohl, vielen Dank soweit; das war genau das, was ich gebraucht habe! :-)
Allerdings habe ich noch ein kleines Verständnisproblem: Der zu
übergebende String lautet natürlich nicht "bla; bla", sondern es handelt
sich um eine komplexe XML-Datei. Der String fängt also schon mit
<?xml version="1.0"
an. Ich hatte nicht geglaubt, dass mein Problem mit der URI-Kodierung zu
tun hat, weil z.B. Frage- und Leerzeichen problemlos durchgingen.
Deswegen nochmal nachgefragt: Warum macht z.B. das Fragezeichen
unkodiert keine Probleme, das Semikolon aber schon?
bis denn
Martin
Peter J. Holzer
> Allerdings habe ich noch ein kleines Verständnisproblem: Der zu
> übergebende String lautet natürlich nicht "bla; bla", sondern es handelt
> sich um eine komplexe XML-Datei. Der String fängt also schon mit
>
><?xml version="1.0"
>
> an. Ich hatte nicht geglaubt, dass mein Problem mit der URI-Kodierung zu
> tun hat, weil z.B. Frage- und Leerzeichen problemlos durchgingen.
> Deswegen nochmal nachgefragt: Warum macht z.B. das Fragezeichen
> unkodiert keine Probleme, das Semikolon aber schon?
Weil das Fragezeichen innerhalb der Parameter keine spezielle Bedeutung
hat. Sonderbedeutung haben "&" und ";" (zur Trennung von Parametern),
"=" (zur Trennung von Paramername und -wert), sowie "%" (zum URL-Encoden).
hp
Ulli Horlacher
> Weil das Fragezeichen innerhalb der Parameter keine spezielle Bedeutung
> hat. Sonderbedeutung haben "&" und ";" (zur Trennung von Parametern),
RFC 2396
2.2. Reserved Characters
Many URI include components consisting of or delimited by, certain
special characters. These characters are called "reserved", since
their usage within the URI component is limited to their reserved
purpose. If the data for a URI component would conflict with the
reserved purpose, then the conflicting data must be escaped before
forming the URI.
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
The "reserved" syntax class above refers to those characters that are
allowed within a URI, but which may not be allowed within a
particular component of the generic URI syntax; they are used as
delimiters of the components
Das Fragezeichen innerhalb der Parameter hat also spezielle Bedeutung.
--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horl...@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/
Peter J. Holzer
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>
>> Weil das Fragezeichen innerhalb der Parameter keine spezielle Bedeutung
>> hat. Sonderbedeutung haben "&" und ";" (zur Trennung von Parametern),
>
> RFC 2396
>
> 2.2. Reserved Characters
>
> Many URI include components consisting of or delimited by, certain
> special characters. These characters are called "reserved", since
> their usage within the URI component is limited to their reserved
> purpose. If the data for a URI component would conflict with the
> reserved purpose, then the conflicting data must be escaped before
> forming the URI.
>
> reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
> "$" | ","
>
> The "reserved" syntax class above refers to those characters that are
> allowed within a URI, but which may not be allowed within a
> particular component of the generic URI syntax; they are used as
> delimiters of the components
>
> Das Fragezeichen innerhalb der Parameter hat also spezielle Bedeutung.
Das folgt aus dem Abschnitt, den Du zitiert hast, aber nicht. Das
Fragezeichen ist in URIs reserviert, weil es <path> und <query> trennt.
Daraus folgt nicht automatisch, dass es in der query reserviert sein
muss.
Du meinst:
| 3.4. Query Component
|
| The query component is a string of information to be interpreted by
| the resource.
|
| query = *uric
|
| Within a query component, the characters ";", "/", "?", ":", "@",
| "&", "=", "+", ",", and "$" are reserved.
Hier ist ? explizit noch mal aufgeführt. Allerdings steht nicht da,
welche Bedeutung das ? hat, und tatsächlich hat es keine, jedenfalls
nicht für CGI.pm oder irgendeine andere <query>-parsende Software, die
mir je untergekommen ist. Zum Parsen der Parameter wird zunächst die
gesamte <query> bei "&" und ";" gesplittet (letzteres ist eine Spezialität
von CGI.pm). Jede Komponente wird dann noch bei "=" in einen
Parameter-Namen und -Wert aufgeteilt. Und zum Schluss werden URI-escapes
aufgelöst. Das "?" kommt in diesem Algorithmus genausowenig wie ein "/"
oder "@" vor. Wenn der Client es verabsäumt, das zu escapen, wird das
Ergebnis genau das gleiche sein, wie wenn er es escapt.
hp
Frank Seitz
>
> | 3.4. Query Component
> |
> | The query component is a string of information to be interpreted by
> | the resource.
> |
> | query = *uric
> |
> | Within a query component, the characters ";", "/", "?", ":", "@",
> | "&", "=", "+", ",", and "$" are reserved.
>
> Hier ist ? explizit noch mal aufgeführt. Allerdings steht nicht da,
> welche Bedeutung das ? hat, und tatsächlich hat es keine, jedenfalls
> nicht für CGI.pm oder irgendeine andere <query>-parsende Software, die
> mir je untergekommen ist.
Das Fragezeichen hat die Bedeutung, dass daran der Query-String erkannt wird.
Wenn das Fragezeichen im URI (einschl. Query-String) nicht geschützt wäre,
gäbe es Mehrdeutigkeiten. Daher ist das Fragezeichen auch im
Query-String geschützt.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Peter J. Holzer
> Peter J. Holzer wrote:
>> | 3.4. Query Component
>> |
>> | The query component is a string of information to be interpreted by
>> | the resource.
>> |
>> | query = *uric
>> |
>> | Within a query component, the characters ";", "/", "?", ":", "@",
>> | "&", "=", "+", ",", and "$" are reserved.
>>
>> Hier ist ? explizit noch mal aufgeführt. Allerdings steht nicht da,
>> welche Bedeutung das ? hat, und tatsächlich hat es keine, jedenfalls
>> nicht für CGI.pm oder irgendeine andere <query>-parsende Software, die
>> mir je untergekommen ist.
>
> Das Fragezeichen hat die Bedeutung, dass daran der Query-String erkannt wird.
> Wenn das Fragezeichen im URI (einschl. Query-String) nicht geschützt wäre,
> gäbe es Mehrdeutigkeiten.
Nein. Es reicht, wenn es im Path geschützt ist. Dann zeigt das erste ?
an, dass der Path zu Ende ist und der Query-String beginnt.
Und noch einmal: Die Frage des OP war: Warum funktioniert das auch, wenn
ich das ? nicht escape. Und die Antwort darauf lautet eben: "Weil der
URL-Parser beim ersten Fragezeichen den Beginn des Query-Strings
feststellt und weiteren ? keine Sonderbedeutung zumisst."
hp
Frank Seitz
> On 2009-03-30 16:09, Frank Seitz <devnu...@web.de> wrote:
>> Peter J. Holzer wrote:
>>> | 3.4. Query Component
>>> |
>>> | The query component is a string of information to be interpreted by
>>> | the resource.
>>> |
>>> | query = *uric
>>> |
>>> | Within a query component, the characters ";", "/", "?", ":", "@",
>>> | "&", "=", "+", ",", and "$" are reserved.
>>>
>>> Hier ist ? explizit noch mal aufgeführt. Allerdings steht nicht da,
>>> welche Bedeutung das ? hat, und tatsächlich hat es keine, jedenfalls
>>> nicht für CGI.pm oder irgendeine andere <query>-parsende Software, die
>>> mir je untergekommen ist.
>> Das Fragezeichen hat die Bedeutung, dass daran der Query-String erkannt wird.
>> Wenn das Fragezeichen im URI (einschl. Query-String) nicht geschützt wäre,
>> gäbe es Mehrdeutigkeiten.
>
> Nein. Es reicht, wenn es im Path geschützt ist. Dann zeigt das erste ?
> an, dass der Path zu Ende ist und der Query-String beginnt.
Das denkst du dir so. Obige Spezifikation, die du selbst herausgesucht hast,
besagt etwas anderes.
> Und noch einmal: Die Frage des OP war: Warum funktioniert das auch, wenn
> ich das ? nicht escape. Und die Antwort darauf lautet eben: "Weil der
> URL-Parser beim ersten Fragezeichen den Beginn des Query-Strings
> feststellt und weiteren ? keine Sonderbedeutung zumisst."
CGI.pm macht es vielleicht so. Nach RFC sind jedoch URL-Parser möglich,
die es anders machen und bei einem ungeschützten ? im Query-String
auf die Nase fallen. Schränke deine Aussagen auf CGI.pm ein, dann sind
sie (vermutlich) ok.
Grüße
Frank Seitz