X-Location Header wird URL-codiert ausgeliefert

Beschreibung

Der Code im StudipController wendet rawurlencode auf die übergebene URL an - das ist aber falsch, das Ergebnis ist dann keine gültige URL mehr (aus https://examplel.com/ wird dabei z.B. https%3A%2F%2Fexamplel.com%2F). Das funktioniert nur deshalb, weil der Header in lib/dialog.js mit decodeURIComponent behandelt wird (was auch nicht korrekt ist, wenn er analog zu dem Location Header funktionieren soll).

added BIEST Version4.5 labels

Das war der Bugfix für Umlaute in der URL:

https://develop.studip.de/trac/ticket/9277

Das hätte damals schon über idn_to_ascii gelöst werden sollen.

assigned to @tleilax

idn_to_ascii ist für Domainnamen gedacht, darum ging es in dem Ticket aber gar nicht. Ich habe mich da eben noch etwas eingelesen, und das Grundproblem ist folgendes:

Aktuelle PHP Versionen (und auch JS) behandeln URLs als UTF-8 Strings. Das funktioniert auch wunderbar, wenn man URLs in HTML-Ausgabe einbettet (oder andere Ausgaben, deren Zeichencodierung sich deklarieren läßt). Leider gibt es aber keinen Weg, die Zeichencodierung von Request- und Response-Headern zu deklarieren. Es gibt einen für Mail-Header (RFC 2047), der wird im HTTP-Bereich aber nicht verwendet. Stattdessen ist die Codierung aus historischen Gründen immer ISO-8859-1 - es wird aber heutzutage empfohlen, nur noch ASCII zu verwenden.

Das führt dazu, daß das Einsetzen einer URL in einen HTTP-Header grundsätzlich problematisch ist. Da wir die URL-Parameter sowieso immer escapen, gibt es nur zwei Bereiche, die bei uns noch Probleme machen können: Der Hostname und der Pfad (inklusive Skriptname). Ersteres wäre ein Thema für IDN, es könnte aber sein, daß PHP sowieso den codierten Namen durchreicht (habe ich nicht getestet). Letzteres (der Pfad) war das Problem in dem oben verlinkten Ticket.

Technisch haben wir das Problem übrigens genauso mit dem Location-Header: Auch in dem Fall produzieren wir einen falsch codierten Header (UTF-8 statt ISO-8859-1), allerdings scheinen Browser damit trotzem umgehen zu können(?). Oder es verwendet einfach niemand solche Zeichen im Pfad der URL.

Korrekt wäre wohl, die bei Location und X-Location verwendete URL so zu codieren, wie encodeURI in JS es tut - aber leider gibt es dazu kein Äquivalent in PHP. Oder wir verbieten die Verwendung von nicht-ASCII Zeichen im Pfad.

Ich habe in !352 (merged) mal das Äquivalent für encodeURI() gebaut und die Stellen angepasst.

Natürlich gibt es auch die Option, bgzl. X-Location einfach alles so zu lassen, wie es jetzt ist. Es ist ja nicht kaputt - man muß nur wissen, daß dieser Header URL-codiert werden muß, falls man ihn selbst generiert und nicht relocate verwendet. Der Location Header wäre weiterhin (theoretisch) kaputt, aber vielleicht ist uns das einfach egal, wenn es in der Praxis keine Probleme macht.

mentioned in commit 38743404

mentioned in merge request !352 (merged)

closed with commit 38743404

closed with merge request !352 (merged)

mentioned in commit 49e107fc

Merge to SVN:

• 4.6
• 4.5

changed milestone to %Stud.IP 4.5.6