Webhosting: Dateiname mit Tilde (~) an erster Stelle nicht erreichbar?

  • Guten Tag,

    ich bin Neukunde bei netcup und entsprechend auch noch neu was die Einstellmöglichkeiten der Webhosting-Pakete betrifft.

    Auf dem Server habe ich im Verzeichnis meiner Domain eine Datei Namens "~test.txt" angelegt, jedoch Endet ein Aufruf immer in 404 not found. Selbes gilt für jegliche Zugriffe auf einen Ordner mit dem Muster "/~test/...". Ersetzt man die Tilde durch ein beliebiges anderes Zeichen geht es.

    Meine Vermutung wäre, dass die Tilde in irgend einer Forum umgeschrieben wird, etwa zu einem User-Verzeichnis. Doch ich weiß nicht genau wie man dies abschalten kann. Im access_log tauch der Aufruf auf, ein Rewrite per .htaccess dagegen ist nicht möglich, dort scheint der Aufruf nicht anzukommen.

    Jemand eine Idee? ?(

  • In einem Unix Betriebssystem beschreibt die Tilde den Pfad zum Homeverzeichnis des Users. Bei Webservern wurde teilweise komisches Zeug gemacht, der Ordner "~test" könnte also auf das Homeverzeichnis des Users "test" zeigen. Deshalb sollte man Tilden nicht in Datei/Ordnernamen verwenden:

    http://jkorpela.fi/tilde.html

    Meine Vermutung ist, dass du das nicht abschalten kannst. Weiterhelfen kann dir aber vermutlich nur der Support. (Das hier ist ein Userforum, Netcupmitarbeiter erreicht man über das Supportforumlar)

  • Hallo Steini,

    auch wenn es nicht empfohlen wird, so ist die Tilde aber auch nicht explizit verboten und es sollte eigentlich möglich sein diese beliebig zu nutzen ohne, dass der Server hier eine Veränderung vornimmt, die immer zu einem negativen Ergebnis führt. Würde dies auf eine unglückliche Serverkonfiguration zurückführen.

    Bin mit einer alten Webseite umgezogen, welche diese Struktur in den URLs für verschiedene Ressourcen nutzt. Werde versuchen sie on-the-fly umzuschreiben auf ein anderes Zeichen, dann sollte es zumindest erst mal funktionieren :)

    Den Support hatte ich auch zuerst angeschrieben, da ich bereits davon ausging, dass es eine Systemeinstellung ist auf die ich keinen Zugriff habe - ist schließlich "nur" ein Webhosting-Paket - und dies erfragen wollte. Leider gab es hier nur eine nicht hilfreiche Standardantwort, was ich etwas enttäuschend fand:

  • Bei Webservern wurde teilweise komisches Zeug gemacht, der Ordner "~test" könnte also auf das Homeverzeichnis des Users "test" zeigen.

    Auch kann ich mit der cd Binary mit cd ~username  in das Heimverzeichnis von User springen.

    Das wird bei (f)open Syscalls nicht anders sein, deswegen wird es bei relativen Pfadbezeichnern zu solchen Problemen kommen.

    Faustregel: reguläre Dateinamen beginnen mit einem alphanumerischen Zeichen aus dem ASCII-Zeichensatz.

  • Das wird bei (f)open Syscalls nicht anders sein, deswegen wird es bei relativen Pfadbezeichnern zu solchen Problemen kommen.

    Ich würde trotzdem erwarten, dass man die angeforderte URL so wie sie ist per htaccess mod_rewrite umschreiben kann, aber so weit kommt es ja garnicht erst. Ob sich ein Pfad im System mit der Tilde dann aufrufen lässt ist nochmal eine andere Sache. Dies mag eine Einstellung des Servers sein.

    Das Problem ist eine Altlast von einem älteren Projekt, habe es durch Tausch der Tilde in ein anderes Zeichen aber auch zum Laufen bekommen. :thumbup:

  • Kann leider nicht mehr editieren, daher schreibe ich es in einen neuen Beitrag.

    Auf meinem Server kann ich problemlos auf eine Datei

    Code
    /~test.txt

    zugreifen, auch wenn ich das Zeichen nicht durch %7E ersetze. Ich verwende Ubuntu 18.04 mit Apache/2.4.34

  • Die Geschichte mit der Encodierung zu %7E hatte ich am Anfang auch mal getestet, macht jedoch keinen Unterschied, kommt aber im Log an:

    Code
    "GET /test.txt HTTP/1.0" 200 <-- klappt
    "GET /~test2.txt HTTP/1.0" 404 <-- nicht gefunden
    "GET /%7Etest2.txt HTTP/1.0" 404 <-- nicht gefunden

    Die Webhosting-Pakete laufe auch mit Debian und anderen Einstellungen. Kann ja sein, dass der Server wirklich versucht die Dateien in einem nicht vorhandenen User-Verzeichnis zu öffnen und das Verhalten je nach Linux/Apache Konfiguration unterschiedlich ist.