"File not found" im error.log mit Pretty-URLs

[dc2]

Hallo,

ich bin auf ein kleines Problem beim Einsatz von Pretty-URLs (mit Hierarchy) gestoßen. Und zwar kommt in meinem error.log regelmäßig eine Meldung wie diese hier vor:

[Sun Jun 20 00:50:15 2010] [error] [client ***.***.***.***] File does not exist: /var/www/anno/www/alias

Wobei "alias" hier für die Alias der obersten Seite in der Hierarchie steht (also bei /kategorie/unterkategorie/seite.htm wäre alias = "kategorie").

Weiß jemand, wie ich dem vorbeugen kann - dadurch wird die Logdatei ziemlich unübersichtlich, an "guten" Tagen sind das locker 200-300 dieser Einträge.

[NaN]

Du bekommst diese Meldung, weil irgendwelche Clients auf Ressourcen zuzugreifen versuchen, die es nicht gibt.
Also wird höchstvermutlich irgendwo irgendwer auf sie verlinkt haben.

Oder aber jemand sucht nach Sicherheitslücken auf Deinem Server.
/kategorie/unterkategorie/seite.htm sieht ja so aus als wären das reale Verzeichnisse mit realen Dateien.
Das könnte dazu verleiten, über eine Sicherheitslücke schadhaften Code in diese "Verzeichnisse" hochzuladen und später auszuführen. (In Deinem Fall scheint beides nicht funktioniert zu haben - Dank Pretty-URLs)
Such also auch mal in den Apache Access-Logs nach verdächtigen Einträgen die ebenfalls auf diese "Alias-Verzeichnisse" zugreifen wollen.

Google und "Apache error.log File does not exist:" sollten da auch einige Beispiele und evtl. Lösungen liefern.
Eine mögliche Lösung wäre z.B. das Stichwort "bot trap". Ist aber nichts für technisch weniger versierte Leute.
Das Beste wäre allerdings, sich auch mit dem Provider in Verbindung zu setzen.

[dc2]

Hab gerade nochmal die Logfiles genauer studiert - die Zugriffe kommen eigentlich alle von "ganz normalen" IP-Bereichen (Telekom (DE/AT), Vodafone, Alice) ich würde versuchte Bot-Angriffe also ausschließen.

Referer (falls vorhanden), die zu den Fehlern führen, sind auch fast immer eigene Seiten, die definitiv nicht auf dieses Verzeichnis verlinken.

Ich vermute, dass irgendein verwirrter Browser versucht, auf die Verzeichnisse zuzugreifen. Möglicherweise, um ein Favicon zu laden (obwohl in der Logdatei dann ja eigentlich ein fehlgeschlagener Zugriff auf die favicon.ico verzeichnet sein müsste).

Andere Sache, die vielleicht wichtig ist: Die Aliasen sind auch selbst Seiten mit Inhalt (Beispiel: http://www.worldofanno.de/anno-1404.htm ist einerseits Kategorie, andererseits selbst eine Seite mit Inhalt)

[NaN]

Also .../anno-1404/allgemein/das-spiel.htm ist eine Seite.
Allerdings ist .../anno-1404 oder .../anno-1404/allgemein eigentlich keine gültige URL.
Denn ohne das .htm am Ende sieht es für den Server aus wie ein Verzeichnis. Welches allerdings nicht existiert. Daher wird intern einfach auf index.php?page=anno-1404 bzw. index.php?page=anno-1404/allgemein umgeleitet. Da du aber eine Dateinamenerweiterung namens .htm verwendest, dürfte CMSms keine derartige Seite finden.
Bei ersterem wird in Deinem Falle aber einfach auf .../anno-1404.htm umgeleitet.
Letzteres führt jedoch zur 404 Fehlerseite (was mit Deiner eigenen 404er Seite übrigens ganz gut aussieht )

Wenn ich allerdings .../anno-1404/allgemein.htm eingebe, dann erhalte ich eine Seite ohne Inhalt.

Jetzt bin ich etwas verwirrt.
Wie erreichst Du denn diese Umleitung von .../anno-1404 auf .../anno-1404.htm ?
Und wieso greift das nicht bei .../anno-1404/allgemein ? (ich vermute mal das ist eine Abschnittsüberschrift?)
Wie sieht denn die Seitenstruktur aus und welche Inhaltstypen sind die einzelnen Seiten?

Ich bin mir gerade nicht sicher, ob der Fehler im Log vom CMS oder von den Umleitungen (z.B. via .htaccess) oder eben doch durch den aufrufenden Client verursacht wird. (Dass die IP Adressen von "normalen" Anbietern kommen hat eigentlich nichts zu sagen. Es heißt ja nicht, dass z.B. die Telekom selbst auf Deine Seite zugegriffen hat, sondern nur, dass der Dienst über den auf Deine Seite zugegriffen wurde von der Telekom bereitsgestellt wurde. Wer tatsächlich dahinter steckt, weiß nur die Telekom selbst - wenn überhaupt. Es könnte z.B. auch ein infizierter Rechner sein.)

Das mit dem Favicon kann ich mir auch nicht vorstellen, zumal Du ja den korrekten Pfad explizit angibst und das Icon auch dargestellt wird. Was sagen denn die Logdaten über die jeweiligen Useragents? Dann könnte man evtl. herausfinden, ob es nur bei bestimmten Browsern passiert.

Vielleicht sind es auch einfach nur dämliche Bots.

Wenn der Referrer Deine eigene Seite ist, dann würde ich die Seiten nochmal ganz genau prüfen.
In HTML Quelltext steht z.B. im Header


World of Anno
...


bzw. im footer gibt es einen link:



könnte es durchaus sein, dass für irgendeinen verwirrten  Browser die URL in



resultiert.

Und jetzt ist die Frage, wie der Browser bzw. der Server mit solchen Anfragen umgeht.

Ich bin ich solchen Sachen leider auch nicht besonders fit.
Alles was ich tun kann, sind derartige Analysen, die evtl. irgendjemanden auf die Lösung bringen.

[dc2]

.../anno-1404/allgemein ist eine Abschnittsüberschrift, genau - ich liste kurz die Struktur schematisch auf:

Anno 1404 (Inhalt)
 > Allgemein (Abschnittsüberschrift)
    > Das Spiel (Inhalt)

Deshalb funktioniert /anno-1404.htm, aber nicht /anno-1404/allgemein.htm (leere Seite, das macht CMSMS ja immer so bei Abschnittsüberschriften - mir würde eine Umleitung auf die Fehlerseite besser gefallen).

Um den Fehlermeldungen vorzubeugen hatte ich versucht, ungültige Verzeichnis-Aufrufe ohne .htm (also z.B. /anno-1404/) per RewriteRule auf die richtige Adresse umzuleiten - das allerdings hat nichts gebracht.

Code: Select all

RewriteRule ^anno-([0-9]+)/?$ anno-$1.htm [R=301,L]

Daher kommt das etwas uneinheitliche Verhalten bei Aufrufen ohne .htm (normalerweise kommt ein 404er).

Leider steht in den Logfiles nichts zum UserAgent, das wäre in der Tat sehr interessant zu wissen.



Edit: Ich hab die Seite eben mal im Internet-Explorer (8) aufgerufen - es funktioniert alles einwandfrei, allerdings befinden sich jetzt entsprechende Zeilen in der Logdatei mit meiner IP-Adresse und derselben Zeit zu der ich mit dem IE aktiv war. Ich hab auch nicht die fraglichen Links im Header / Footer genutzt.

Der IE scheint da also irgendwas eigensinniges zu machen.

[NaN]

Wie kommt denn das base tag zustande?
Ist das hardcoded oder mit Hilfe von {metadata}?
Vielleicht ist es der Schrägstrich am Ende vom Base tag, der diesen Fehler verursacht.
In sämtlicher Literatur oder Beispielseiten wird die base URL immer ohne Schrägstrich am Ende angegeben.
Gerade beim IE sollen speiziell bei "falschen" base Angaben Probleme auftreten.

[dc2]

Hab eben mal nachgeschaut - der -tag kommt von {metadata}-Plugin - ich hab die Datei mal entsprechend bearbeitet und den abschließenden Slash entfernt - hat aber leider nichts gebracht.

Das ist wirklich komisch

Edit: Noch ein Grund mehr, den IE abgrundtief zu hassen
Ich habe die Umleitung von /anno-1404/ und Co. auf die Version mit .htm jetzt erstmal auskommentiert - bringt ja im Prinzip nichts und kostet im Zweifelsfall nur Performance.

[nhaack]

Ein Klassiker bei solchen Themen ist oft, dass man irgendwo im Template (der Seite oder auch MenuManager) noch eine fehlerhafte Verlinkung drin hat.... weil die Page auf der Dev-Instanz mal anders hieß (und fest einprogrammiert ist), weil die URL-Struktur im dritten Anlauf anders aufgebaut wurden etc pp

Hier mit Redirects zu arbeiten wäre nur eine Behelfslösung, wie du schon richtig erkannt hast kostet Rewriting vergleichsweise viel Rechenleistung. Daher macht es Sinn ein wenig tiefer zu forschen und das Problem an der Wurzel zu lösen, so dass solche Verlinkungen garnicht erst präsentiert werden.

Crawl doch deine Site einmal mit XENU durch. Du bekommst am Ende einen Report mit den fehlerhaften Seiten und auch, von wo diese Seiten fehlerhaft verlinkt wurden (intern). Das hilft, sofern das Problem hausgemacht ist, die Fehlerquelle einzugrenzen.

Ich persönlich lasse Dateiendungen nach Möglichkeit weg und auch immer mit Slash am Ende. Ich finde, das macht das URL Handling wesentlich leichter

Da fällt mir gerade ein, man könnte die Abschnittsüberschrift als einzelne richtige Seiten anlegen. Im Template wäre dann nur der Aufruf eines kleinen UDT, dass einen 301 Redirect auf die gewünschte Seite abfeuert. Der Template Body wird zuerst interpretiert, so kannst du Statuscodes auch von einem UDT aus senden und dem CMS zuvorkommen ... nicht ganz sauber und auch keine eigentliche Problemlösung, funktioniert aber trotzdem ganz gut.

Grüße
Nils

[dc2]

Hab mal einen XENU-Durchlauf gemacht und bin zu dem Ergebnis gekommen, dass alles korrekt verlinkt ist.

Einzige Fehler waren ausgehende Links und interne Verlinkungen waren alle korrekt (also ohne Redirects).


Wie ich schon rausgefunden hatte kommen diese Fehler auch nur bei Nutzung des IE - irgendwas komisches muss der da veranstalten^^

[NaN]

Eventuell hilft Dir ja das hier weiter: http://www.joewein.net/info/sw-msoffice-vti-bin.htm

[dc2]

Leider auch nicht
Die Fehler tauchen auch auf, wenn ich selbst die Seiten mit dem IE aufrufe - und ich hatte auf diesem Rechner hier noch nie Office installiert.

Schon komisch^^

[Andiministrator]

Also ich würde mal noch an folgenden Stellen suchen:

1. Link-Validierung
http://validator.w3.org/checklink?check=Check&hide_type=all&summary=on&uri=http%3A%2F%2Fwww.worldofanno.de%2Fallgemeines%2Fallgemein-3%2Fdie-entwickler-von-anno.htm

2. JavaScript/Ajax Aufrufe
Du kannst die Javascript/Ajax Aufrufe ja mal alle rausnehmen und der Reihe nach wieder rein, vielleicht ist dort was faul.

3. Base URL
Ohne da jetzt etwas getestet zu haben, aber ich würde die Base-URL immer mit abschließendem / einfügen, also:

4. CSS Validierung
Vielleicht ist ja auch irgendwo in den CSS ein fehlerhafter Aufruf?
http://jigsaw.w3.org/css-validator/validator?profile=css21&warning=0&uri=http%3A%2F%2Fwww.worldofanno.de%2Fallgemeines%2Fallgemein-3%2Fdie-entwickler-von-anno.htm

Also, viel Erfolg bei der Fehlersuche!