"Halb-Relative" URLs bei Redirect

[Patrick Canterino]

Hallo Forumer,

wenn hier Fragen zu solchen Dingen wie
header("Location ...");
auftauchen, wird ja immer wieder gesagt, dass dabei relative URLs nicht erlaubt sind.

Mich würde mal interessieren, ob aber sowas wie
http://www.domain.tld/ordner1/ordner2/../ordner3/../../ordner4/test.htm
erlaubt ist.
Ich habe mir zwar die RFC 2396 (in der ist das definiert) angesehen, aber so richtig schlau wurde ich daraus nicht.

Funktionieren tut's auf jeden Fall (getestet mit Firefox, Internet Explorer, wget, libwww-perl und PHP).

Viele Grüße
  Patrick Canterino

[Christian Seiler]

Hallo Patrick,

wenn hier Fragen zu solchen Dingen wie
header("Location ...");
auftauchen, wird ja immer wieder gesagt, dass dabei relative URLs nicht erlaubt sind.

Mich würde mal interessieren, ob aber sowas wie
http://www.domain.tld/ordner1/ordner2/../ordner3/../../ordner4/test.htm
erlaubt ist.

Es ist eine gültige URI, da die Zeichen "." und "/" in Pfaden durchaus erlaubt sind. Allerdings stellt sich die Frage, ob diese URI auch überall korrekt interpretiert wird. Ich zitiere dazu mal aus dem Sicherheitsteil von RFC 2616 (der HTTP-Spec):

[...] If an HTTP server translates
   HTTP URIs directly into file system calls, the server MUST take
   special care not to serve files that were not intended to be
   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
   other operating systems use ".." as a path component to indicate a
   directory level above the current one. On such a system, an HTTP
   server MUST disallow any such construct in the Request-URI if it
   would otherwise allow access to a resource outside those intended to
   be accessible via the HTTP server. [...]

Das heißt also: es hängt vom Webserver und vom Betriebsystem ab, ob ".." interpretiert wird (der Passus "MUST disallow" darf hier nicht abschrecken, er bezieht sich nur auf die Tatsache, dass zu viele "../" nicht zur Auslieferung von höhergehende Dateien, als im DocumentRoot, führen darf, was bei Dir ja nicht gegeben ist).

Wenn Du also sicherstellen kannst, dass der _Webserver_ (an den der Browser die Anfrage ja schickt), damit umgehen kann, wirst Du keine Probleme haben. Denn Du kannst es mit zwei Typen von Browsern zu tun haben: Der erste Typ wird die "../" selbstständig rausfiltern. Ich weiß nicht, ob so etwas bei Location-Headern gemacht wird bzw. überhaupt erlaubt ist. Der zweite Typ, der von "../" nichts weiß, wird den Pfad-Teil des URI unverändert an den Webserver weiterleiten - und wenn der das schluckt (ist beim Apache z.B. der Fall), dann hast Du keine Probleme, denn Dir kann es egal sein, wo die "../" aufgelöst werden.

Viele Grüße,
Christian

[Patrick Canterino]

Hallo Christian,

danke für deine Antwort!

Ich wollte das wissen, weil ich für ein Script etwas schreiben will, dass versucht, relative URLs in absolute umzuwandeln. Da ich zu faul bin, jedes ".." aufzulösen, wollte ich es so machen.
Wenn es wegen solchen URLs Probleme gibt, kann man ja immer noch vollständig absolute nehmen.

Viele Grüße
  Patrick Canterino

[wahsaga]

hi,

Ich wollte das wissen, weil ich für ein Script etwas schreiben will, dass versucht, relative URLs in absolute umzuwandeln. Da ich zu faul bin, jedes ".." aufzulösen, wollte ich es so machen.

wenn du mit PHP arbeitest, schau dir doch mal http://www.php.net/manual/de/function.realpath.php an.

das unterstützt in diesem falle deine "faulheit" auf recht hilfreiche weise :-)

gruß,
wahsaga

[Patrick Canterino]

Hallo wahsaga,

wenn du mit PHP arbeitest, schau dir doch mal http://www.php.net/manual/de/function.realpath.php an.

das unterstützt in diesem falle deine "faulheit" auf recht hilfreiche weise :-)

realpath() löst doch nur relative Pfade im Dateisystem auf und funktioniert bei URLs nicht. Oder meinst du was anderes?

Viele Grüße
  Patrick Canterino

[wahsaga]

hi,

realpath() löst doch nur relative Pfade im Dateisystem auf und funktioniert bei URLs nicht.

stimmt, da hast du recht.
und funktioniert wohl auch nur bei wirklich existierenden dateien.

:-/

gruß,
wahsaga