RewriteRule vs ProxyPass - für Nextcloud entscheidend

Die Zeichen \ / : ? * " < > | sowie führende und angehängte Leerzeichen in Datei- und Verzeichnisnamen sind generell problematisch und können auf einigen Systemen gar nicht verwendet werden, beispielsweise das Fragezeichen unter Windows.

Wird z.B. unter Linux oder im Nextcloud-GUI eine Datei mit ? im Namen angelegt (vorausgesetzt, die nur für das Nextcloud Web-GUI gültigen forbidden_chars sind nicht konfiguriert), verweigert der Nextcloud-Client unter Windows die Synchronisation mit der Meldung File names containing the character "?" are not supported on this file system.

Die Lösung ist eigentlich ganz einfach: Die Datei im Nextcloud-GUI umbenennen und die Sonderzeichen ersetzen oder entfernen. In letzter Zeit gab das Web-GUI bei dieser Aktion aber immer die Fehlermeldung File not found aus. Seltsam.

Bug oder nicht?

Ist das ein Bug in Nextcloud oder liegt es an der Umgebung, in der die Anfrage durch eine Kette von Firewalls, WAFs und Reverse-Proxies bis zum Nextcloud-Applikationsserver durchgereicht wird?

Wir haben das Szenario erst einmal in einem lokalen Docker-Container nachgestellt. Die Überraschung war gross, als das Umbenennen dort funktioniert hat – damit war aber auch klar, wo wir suchen mussten.

Als erstes haben wir die Logfiles des Apache-Webservers auf dem Reverse-Proxy und dem Backend Server untersucht. Beim Umbenennen der Datei Textdatei ?.md in Textdatei ??.md im Web-GUI sendet der Browser zunächst die URI /remote.php/dav/files/admin/Text%20datei%20%3F.md (man beachte das URL-Encoding). Diese kommt genau so auf dem Reverse-Proxy an.

Der Request auf dem Nextcloud Applikationsserver hatte jedoch die Form /remote.php/dav/files/admin/Text%20file%20?.md. Das Fragezeichen wurde hier also nicht encoded. Nextcloud findet die Datei daher nicht und kann sie auch nicht umbenennen, was die Fehlermeldung im Web-GUI erklärt.

Die Ursache

Auf dem Apache Reverse-Proxy haben wir in der Konfiguration des Nextcloud-vHosts aus Gründen der Flexibilität auf RewriteRule statt ProxyPass-Direktiven gesetzt. Die letzte Regel in unserer umfangreichen RewriteRule-Liste lautete RewriteRule ^/(.*) http://nc.example.com/$1 [proxy,last].

Im Gegensatz zu ProxyPass dekodiert RewriteRule jedoch das Pattern ^/(.*), was auch in der Dokumentation beschrieben wird: In VirtualHost context, The Pattern [...] is the (%-decoded) URL-path. Da wir in der Direktive die gesamte URI matchen und über $1 referenzieren, wird am Ende auch die Substitution http://nc.example.com/$1 dekodiert. Das erklärt, warum das Fragezeichen unkodiert an Nextcloud weitergegeben wurde.

Die Lösung

Wir haben folgende Varianten von RewriteRule und ProxyPass getestet:

Obwohl RewriteRules wesentlich flexibler sind, haben wir uns letztendlich für die ProxyPass-Anweisung entschieden, da sie deutlich besser lesbar ist. Den leichten Performance-Vorteil nehmen wir natürlich auch gerne mit.

Ausblick

Wie kann nun verhindert werden, dass Dateien und Verzeichnisse mit problematischen Zeichen angelegt werden? Um dies im Nextcloud Web-GUI zu verhindern, kann eine Liste von forbidden_chars definiert werden. In der aktuellen Nextcloud Version 28 (Stand 2024-03) gibt es jedoch keine Möglichkeit, einen Client daran zu hindern, solche Dateien zu synchronisieren. Nextcloud arbeitet an einer Lösung für dieses Problem, die voraussichtlich in Nextcloud 29 verfügbar sein wird (siehe Issue 31663 und Issue 38614).

Bis dahin gilt: Reverse-Proxy richtig konfigurieren 😉 und anschliessend Dateien mit problematischen Zeichen im Web-GUI umbenennen.