URI syntax

[Gunnar Bittersmann]

Hallo,
Ich werd nicht ganz schlau aus [RFC2396], §3.4:
   Within a query component, the characters ";", "/", "?", ":", "@",
   "&", "=", "+", ",", and "$" are reserved.

Ist
   http://www.songklub.de/index.htm?/festival/2005/programm.htm
ein gültiger URI oder müssen die "/" nach dem "?" escapet werden:
   http://www.songklub.de/index.htm?%2Ffestival%2F2005%2Fprogramm.htm

Ersteres (mit "/")geht, mit letzterem (mit "%2F") bekommt man vom Server eine Fehlermeldung. (Deshalb auch nicht verlinkt, und das erste akzeptiert die Forumsoftware nicht zur Verlinkung.)

Gruß,
Gunnar

[Cybaer]

Hi,

Ersteres (mit "/")geht, mit letzterem (mit "%2F") bekommt man vom Server eine Fehlermeldung.

Ein Fehler dort.

Escapen ist korrekt.

Gruß, Cybaer

[Cheatah]

Hi,

noch ein kleines Augenzwinkern:

Ist
   http://www.songklub.de/index.htm?/festival/2005/programm.htm
ein gültiger URI oder müssen die "/" nach dem "?" escapet werden:

Rate mal, warum http://www.songklub.de/index.htm?/festival/2005/programm.htm hier nicht angenommen wird ;-)

Cheatah

[Gunnar Bittersmann]

Cheatah,

Rate mal, warum http://www.songklub.de/index.htm?/festival/2005/programm.htm hier nicht angenommen wird ;-)

Das nimmt aber deren Webserver an. Die Version mit "%2F" nicht.

Abschnitt 2.4.2 von [RFC2396] und [molily] lassen mich eher glauben, dass die "/" nicht escapet werden müssen.

Aus Collected BNF for URI (Anhang A von [RFC2396])
      relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]
      hier_part     = ( net_path | abs_path ) [ "?" query ]
      query         = *uric
      uric          = reserved | unreserved | escaped
      reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                      "$" | ","
lese ich, dass "/" beliebig vorkommen darf, aber reserviert ist, wofür auch immer.

Gunnar

[molily]

Hallo,

In RFC 1738 ist »/« unmaskiert in der Query-Komponente definitiv verboten. Gemäß RFC 2396 ist es offenbar erlaubt, da stimme ich deiner Lesart zu. Man kann sich darüber streiten, was nun normativ für HTTP gilt. HTTP 1.1 verweist auf RFC 2396 als normative Grundlage für HTTP-Adressen, welches seinerseits RFC 1738 »aktualisiert« (»updates RFC 1738«).
Auf Basis dieser Fakten bin ich der Meinung, dass man deine Beispieladressen als gültig ansehen kann. Ich schließe aber nicht aus, dass sie Probleme bereiten können und dass es aus praktischen Gründen ratsamer ist, sich am älteren, strengeren RFC zu orientieren.
Die Prüfroutine hier im Forum legt eben RFC 1738 zugrunde (http://example.org/?$-_.+!*'(),;:@&= geht z.B., weitere Zeichen, die in RFC 2396 im Query erlaubt sind, toleriert die Routine eben nicht).

Mathias

[Henryk Plötz]

Moin,

Rate mal, warum http://www.songklub.de/index.htm?/festival/2005/programm.htm hier nicht angenommen wird ;-)

Das nimmt aber deren Webserver an. Die Version mit "%2F" nicht.

uric          = reserved | unreserved | escaped
      reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                      "$" | ","
lese ich, dass "/" beliebig vorkommen darf, aber reserviert ist, wofür auch immer.

Ich stimme zu. RFC 1738 war für HTTP-URLs zuständig und ist so hier auch implementiert. RFC 2396 sagt dass es das allgemeine URL-Format regelt aber die Vorgaben für einzelne URL-Schemen aus RFC 1738 nicht antastet bis ein RFC kommt der sich ausdrücklich mit dem jeweiligen Schema befasst. Für einige Schemen (wie mailto, RFC 2368) gibt es die, für HTTP noch nicht ausdrücklich. Allerdings enthält RFC 2616 ausdrücklich einen Verweis auf 2396 mit der Angabe dass dieser authoritativ sei. Weiterhin findet sich dort ein vereinfachtes Format für HTTP-URLs welches das Nicht-Terminal query enthält. Dessen Definition hast du ja oben zitiert und da geht klar hervor dass / auch unkodiert vorkommen darf.

Weiterhin ist den diversen Quellen zu entnehmen dass / im query-Part reserviert ist, und über reservierte Zeichen wird gesagt dass sie unkodiert vorkommen dürfen wenn sie eine besondere Bedeutung haben. Das ist hier ja offensichtlich der Fall.

Schlussfolgerung: ein URL der Art http://...?../.. ist unter gewissen Umständen legal. Umstände die die Forumssoftware nicht automatisch erkennen kann, also sollte sie solche URLs in jedem Fall akzeptieren.

[molily]

Rate mal, warum http://www.songklub.de/index.htm?/festival/2005/programm.htm hier nicht angenommen wird ;-)

Das nimmt aber deren Webserver an. Die Version mit "%2F" nicht.

Dem Webserver ist es das relativ egal: Der nimmt (als HTTP-Anfrage) beides an. Ob den Adressen dabei eine Ressource auf dem Server entspricht, ist eine andere Frage.

Das Problem bei obiger URI ist, dass der Query-String über JavaScript ausgelesen wird und dann damit das Frameset gefüllt wird:

var dokument=location.search;
if(dokument)
frames.rechts.location.href=dokument.substring(1,dokument.length);

Bei der URI http://www.songklub.de/index.htm?/festival/2005/programm.htm ist location.search gleich »?/festival/2005/programm.htm«. Daraus baut das Script die relative Adresse »/festival/2005/programm.htm« zusammen, welche dem einen Frame zugewiesen wird. An den Server wird dann »GET /festival/2005/programm.htm HTTP/1.1« geschickt, was problemlos funktioniert und die gewünschte Seite liefert.

Bei der URI http://www.songklub.de/index.htm?%2Ffestival%2F2005%2Fprogramm.htm ist location.search gleich »?%2Ffestival%2F2005%2Fprogramm.htm«. Daraus baut das Script die relative Adresse »%2Ffestival%2F2005%2Fprogramm.htm« zusammen, welche dem einen Frame zugewiesen wird. An den Server wird dann »GET %2Ffestival%2F2005%2Fprogramm.htm HTTP/1.1« geschickt, was ein ein 404 Not Found erzeugt, denn eine Ressource mit diesem Namen gibt es auf dem Server nicht (weil »/« nicht in Dateinamen vorkommen kann).

Es ist also eine Unzulänglichkeit des Scripts. Es hätte »%2F« durch »/« ersetzen müssen. Leider bedenken die wenigsten »Frame-Nachlade-Scripte« dies und erzeugen a) nicht RFC-1738-konforme URLs und b) nehmen keine RFC-1738-konformen URLs entgegen.

Mathias

[Gunnar Bittersmann]

Danke, Jungs.

Dann werd ich den Usern wohl besser die Variante mit "/" anbieten. Dass der URI nicht RFC-1738-konform ist, dürfte für diese von weniger Interesse sein als ob der Link sie ans Ziel führt.

Gruß,
Gunnar